Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > A suggestion

Reply
Thread Tools

A suggestion

 
 
Michael Doubez
Guest
Posts: n/a
 
      01-16-2011
On 16 jan, 15:06, "Paul" <(E-Mail Removed)> wrote:
> "Michael Doubez" <(E-Mail Removed)> wrote in message
>
> news:(E-Mail Removed)...
> On 16 jan, 01:19, "Paul" <(E-Mail Removed)> wrote:
>
>
>
> > "Michael Doubez" <(E-Mail Removed)> wrote in message

>
> >news:(E-Mail Removed)...
> > On 14 jan, 15:56, "Paul" <(E-Mail Removed)> wrote:

>
> > > "Michael Doubez" <(E-Mail Removed)> wrote in message

>
> > >news:(E-Mail Removed)...

>
> > > > On 13 jan, 20:28, "Paul" <(E-Mail Removed)> wrote:
> > > >> "Michael Doubez" <(E-Mail Removed)> wrote in message

>
> > > >>news:(E-Mail Removed)...

>
> > > >> > On 13 jan, 13:12, Stuart Redmann <(E-Mail Removed)> wrote:
> > > >> >> I just read some of the follow-ups in one of your recent threads
> > > >> >> ("Newbies don't learn C++ Optionen"), and I glimpsed something
> > > >> >> that
> > > >> >> caught my attention. One of the points in the discussion was
> > > >> >> whether
> > > >> >> a
> > > >> >> member function is "part of" an object or not (the "member
> > > >> >> functions"
> > > >> >> thread), where "part of" could be interpreted quite differently
> > > >> >> depending on the personal point of view of the reader.

>
> > > >> >> A scenario where a member function will most probably be
> > > >> >> considered
> > > >> >> as
> > > >> >> "part of" an object by everyone would be if it was possible to
> > > >> >> give
> > > >> >> each object a separate "copy" of the same member function, so that
> > > >> >> each object can modify it (self-modifying code).

>
> > > >> > A copy of what ? In the c++ model, functions are not object and
> > > >> > thus
> > > >> > cannot be contained within a object. You can store objects (ex:
> > > >> > function pointer or lambda) that achieves what you say but they are
> > > >> > member objects, not member functions.

>
> > > >> An object is the concept of a data structure which consists of member
> > > >> data
> > > >> and member functions. This is as much a fact as the fact that the sky
> > > >> is
> > > >> blue.

>
> > > > No it is not, except in vulgarisation magazines. A more precise
> > > > definition is "an object is an instance of the data structure and
> > > > behaviour defined by the object's class". You cannot make abstraction
> > > > of the class concept, otherwise, you don't have the model for the
> > > > object's state, methods and interaction; even if the class is not
> > > > expressed by the language (in some languages where functions are in
> > > > fact data members, like in javascript).

>
> > > I don't abstract the class I have stated many times that an object is
> > > defined by the class.
> > > Whether you call it objects behaviour , method , or member function you
> > > cannot deny that the member function is the objects behaviour.

>
> > > >> C++ was designed to be, or support, object orientated programing in
> > > >> the
> > > >> context of my above definition. This is the main reason why member
> > > >> functions
> > > >> exist and this is primarily what a member function is used for. Any
> > > >> use
> > > >> of a
> > > >> member function, other than as an objects member function, is not its
> > > >> primary intended use.

>
> > > > And I cannot call a function if I don't have an instance of the
> > > > parameters. That doesn't make the function part of the parameters.

>
> > > >> For this reason alone a member function is part of an object as much
> > > >> as
> > > >> the
> > > >> sky is blue.

>
> > > > Actually, it is not but I won't talk about dipole physics here

>
> > > The sky is blue, obviously in daytime( for those who choose to observe
> > > the
> > > sky at night)
> > > I don't know what color the sky is in your world, if not blue.

>
> > I see it blue all right but I know it is composed of layers of gases
> > that are not blue.
> > .................................................. ........

>
> > If you see it as blue thats possibly because it is blue.
> > What color do you suggest it is, if not blue?

>
> To take an example, water is blue; it intrinsecally absorbs and
> scatter white light into blue color. The gazes in the high atmosphere
> are not blue but their interaction and the bias in human eye make it
> seen blue.
>
> If you look at a peace or pure water, it is blue while it is not the
> same for a peace of the gazes that compose the sky.
>
> In that, if the skype was blue, it would color the perception of the
> sun (which would become blueish).
> ********************************************
> Why is this complete rubbish? I will explain:
> If you take a molecule out of the sky and examine it in a different context
> then you are no longer examining the sky.


If you take a molecule of water and examine the color of the light it
difracts, it is blue.
If you take a molecule of gaze and examine the color of the light it
difracts, it is not blue.

In the case of the sky, the factors are more complicated.

>
> You still haven't said what color the sky is in your world. All you do is
> avoid giving any direct answer.


Why ? It is of course violet (because it is the highest wavelength in
the visible spectrum) but you eyes are sensible to green and are 100
times less sensible to violet (photopic vision). Taking the average,
this result in this blue color you (and I) see when not too near the
sun and not too low on the horizon, otherwise the diffusion rules
change (and the color also).

In fact we should talk about the colors of the sky and not the color
of the sky.

> > > >> C++ did *not* set out to support the idea that an object was simply a
> > > >> region
> > > >> of stroage and did not contain member functions. This is simply
> > > >> *******s.

>
> > > > The first name of C++ (1979) was C With class
> > > > Seehttp://www2.research.att.com/~bs/hopl2.pdf
> > > > <quote>
> > > > Even though support of concurrency and Simula-s tyle simulations was a
> > > > primary aim of C with
> > > > Classes, the language contained no primitives for expressing
> > > > concurrency; rather, a combination
> > > > of inheritance (class hierarchies) and the ability to define class
> > > > member functions with special
> > > > meanings recognized by the pre-p rocessor was used to write the
> > > > library that supported the desired
> > > > styles of concurrency.
> > > > </quote>

>
> > > Are you trying to suggest that C++ does not support OOP?
> > > I can provide a hell of alot of quotations that prove C++ does support
> > > OOP,
> > > if you really want to raise an argument about this.

>
> > That is not what I said, I answer that indeed C++ *did* set out to
> > support the idea that an object was simply a region of storage, from
> > the very begining.
> > .................................................. ...........................................

>
> > But C++ does not support the idea that an object is *simply* a region of
> > storage, if this were the case C++ would not support OOP.

>
> It depends on what you put behind that /simply/.
>
> If we limit to the phisical side, from the standard (as quoted) it is
> a memory space and it has a type (and a lifetime). In some cases, RTTI
> may require to put data in the object to retreive the type (ie. the
> information at compile type is not sufficient for type resolution).
> Thus, physically, an object is a piece of memory whatever you can
> observe in term of (member) function you can apply on this piece of
> memory.
> ************************************************** **
> This is not quoted from the standards this is a complete misinterpretation
> by you.
> The standards state 'an object is a region of storage'. There is no /simply/
> in there at all, this has been introduced by you.
>
> An objects member function has calling mechanisms that associate the member
> function with the object. The C++ standards do not detail these calling
> mechanisms because the language would then be tied to hardware that
> supported these calling mechanisms. So it doesn't take a great deal of
> intelligence to realise that C++ standard is the wrong doc to ref in the
> first place.


But a member function expression doesn't link the object to its member
function. It retreives the type of the object (its class) and then
lookup the member function. You see a relation where there is none.

Let say we disagree on this point and let it at that.

Let's try to catch the last ray of light of the sun on a clear sky
above water: it is a green flash (usually on a orange sky but that's
another story).

Cheers

--
Michael
 
Reply With Quote
 
 
 
 
Paul
Guest
Posts: n/a
 
      01-16-2011

"Michael Doubez" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> On 16 jan, 15:06, "Paul" <(E-Mail Removed)> wrote:
>> "Michael Doubez" <(E-Mail Removed)> wrote in message
>>
>> news:(E-Mail Removed)...
>> On 16 jan, 01:19, "Paul" <(E-Mail Removed)> wrote:
>>
>>
>>
>> > "Michael Doubez" <(E-Mail Removed)> wrote in message

>>
>> >news:(E-Mail Removed)...
>> > On 14 jan, 15:56, "Paul" <(E-Mail Removed)> wrote:

>>
>> > > "Michael Doubez" <(E-Mail Removed)> wrote in message

>>
>> > >news:(E-Mail Removed)...

>>
>> > > > On 13 jan, 20:28, "Paul" <(E-Mail Removed)> wrote:
>> > > >> "Michael Doubez" <(E-Mail Removed)> wrote in message

>>
>> > > >>news:(E-Mail Removed)...

>>
>> > > >> > On 13 jan, 13:12, Stuart Redmann <(E-Mail Removed)> wrote:
>> > > >> >> I just read some of the follow-ups in one of your recent
>> > > >> >> threads
>> > > >> >> ("Newbies don't learn C++ Optionen"), and I glimpsed something
>> > > >> >> that
>> > > >> >> caught my attention. One of the points in the discussion was
>> > > >> >> whether
>> > > >> >> a
>> > > >> >> member function is "part of" an object or not (the "member
>> > > >> >> functions"
>> > > >> >> thread), where "part of" could be interpreted quite differently
>> > > >> >> depending on the personal point of view of the reader.

>>
>> > > >> >> A scenario where a member function will most probably be
>> > > >> >> considered
>> > > >> >> as
>> > > >> >> "part of" an object by everyone would be if it was possible to
>> > > >> >> give
>> > > >> >> each object a separate "copy" of the same member function, so
>> > > >> >> that
>> > > >> >> each object can modify it (self-modifying code).

>>
>> > > >> > A copy of what ? In the c++ model, functions are not object and
>> > > >> > thus
>> > > >> > cannot be contained within a object. You can store objects (ex:
>> > > >> > function pointer or lambda) that achieves what you say but they
>> > > >> > are
>> > > >> > member objects, not member functions.

>>
>> > > >> An object is the concept of a data structure which consists of
>> > > >> member
>> > > >> data
>> > > >> and member functions. This is as much a fact as the fact that the
>> > > >> sky
>> > > >> is
>> > > >> blue.

>>
>> > > > No it is not, except in vulgarisation magazines. A more precise
>> > > > definition is "an object is an instance of the data structure and
>> > > > behaviour defined by the object's class". You cannot make
>> > > > abstraction
>> > > > of the class concept, otherwise, you don't have the model for the
>> > > > object's state, methods and interaction; even if the class is not
>> > > > expressed by the language (in some languages where functions are in
>> > > > fact data members, like in javascript).

>>
>> > > I don't abstract the class I have stated many times that an object is
>> > > defined by the class.
>> > > Whether you call it objects behaviour , method , or member function
>> > > you
>> > > cannot deny that the member function is the objects behaviour.

>>
>> > > >> C++ was designed to be, or support, object orientated programing
>> > > >> in
>> > > >> the
>> > > >> context of my above definition. This is the main reason why member
>> > > >> functions
>> > > >> exist and this is primarily what a member function is used for.
>> > > >> Any
>> > > >> use
>> > > >> of a
>> > > >> member function, other than as an objects member function, is not
>> > > >> its
>> > > >> primary intended use.

>>
>> > > > And I cannot call a function if I don't have an instance of the
>> > > > parameters. That doesn't make the function part of the parameters.

>>
>> > > >> For this reason alone a member function is part of an object as
>> > > >> much
>> > > >> as
>> > > >> the
>> > > >> sky is blue.

>>
>> > > > Actually, it is not but I won't talk about dipole physics here

>>
>> > > The sky is blue, obviously in daytime( for those who choose to
>> > > observe
>> > > the
>> > > sky at night)
>> > > I don't know what color the sky is in your world, if not blue.

>>
>> > I see it blue all right but I know it is composed of layers of gases
>> > that are not blue.
>> > .................................................. ........

>>
>> > If you see it as blue thats possibly because it is blue.
>> > What color do you suggest it is, if not blue?

>>
>> To take an example, water is blue; it intrinsecally absorbs and
>> scatter white light into blue color. The gazes in the high atmosphere
>> are not blue but their interaction and the bias in human eye make it
>> seen blue.
>>
>> If you look at a peace or pure water, it is blue while it is not the
>> same for a peace of the gazes that compose the sky.
>>
>> In that, if the skype was blue, it would color the perception of the
>> sun (which would become blueish).
>> ********************************************
>> Why is this complete rubbish? I will explain:
>> If you take a molecule out of the sky and examine it in a different
>> context
>> then you are no longer examining the sky.

>
> If you take a molecule of water and examine the color of the light it
> difracts, it is blue.
> If you take a molecule of gaze and examine the color of the light it
> difracts, it is not blue.
>
> In the case of the sky, the factors are more complicated.
>

This is commplete bullshit ehrher it is french or any other language. Its
simply nomore than bullshitll.
The sky is blue PLANK
>>
>> You still haven't said what color the sky is in your world. All you do is
>> avoid giving any direct answer.

>
> Why ? It is of course violet (because it is the highest wavelength in
> the visible spectrum) but you eyes are sensible to green and are 100
> times less sensible to violet (photopic vision). Taking the average,
> this result in this blue color you (and I) see when not too near the
> sun and not too low on the horizon, otherwise the diffusion rules
> change (and the color also).
>
> In fact we should talk about the colors of the sky and not the color
> of the sky.
>

No the sky is blue. If yo u think otherise that is your choice,.

>> > > >> C++ did *not* set out to support the idea that an object was
>> > > >> simply a
>> > > >> region
>> > > >> of stroage and did not contain member functions. This is simply
>> > > >> *******s.

>>
>> > > > The first name of C++ (1979) was C With class
>> > > > Seehttp://www2.research.att.com/~bs/hopl2.pdf
>> > > > <quote>
>> > > > Even though support of concurrency and Simula-s tyle simulations
>> > > > was a
>> > > > primary aim of C with
>> > > > Classes, the language contained no primitives for expressing
>> > > > concurrency; rather, a combination
>> > > > of inheritance (class hierarchies) and the ability to define class
>> > > > member functions with special
>> > > > meanings recognized by the pre-p rocessor was used to write the
>> > > > library that supported the desired
>> > > > styles of concurrency.
>> > > > </quote>

>>
>> > > Are you trying to suggest that C++ does not support OOP?
>> > > I can provide a hell of alot of quotations that prove C++ does
>> > > support
>> > > OOP,
>> > > if you really want to raise an argument about this.

>>
>> > That is not what I said, I answer that indeed C++ *did* set out to
>> > support the idea that an object was simply a region of storage, from
>> > the very begining.
>> > .................................................. ...........................................

>>
>> > But C++ does not support the idea that an object is *simply* a region
>> > of
>> > storage, if this were the case C++ would not support OOP.

>>
>> It depends on what you put behind that /simply/.
>>
>> If we limit to the phisical side, from the standard (as quoted) it is
>> a memory space and it has a type (and a lifetime). In some cases, RTTI
>> may require to put data in the object to retreive the type (ie. the
>> information at compile type is not sufficient for type resolution).
>> Thus, physically, an object is a piece of memory whatever you can
>> observe in term of (member) function you can apply on this piece of
>> memory.
>> ************************************************** **
>> This is not quoted from the standards this is a complete
>> misinterpretation
>> by you.
>> The standards state 'an object is a region of storage'. There is no
>> /simply/
>> in there at all, this has been introduced by you.
>>
>> An objects member function has calling mechanisms that associate the
>> member
>> function with the object. The C++ standards do not detail these calling
>> mechanisms because the language would then be tied to hardware that
>> supported these calling mechanisms. So it doesn't take a great deal of
>> intelligence to realise that C++ standard is the wrong doc to ref in the
>> first place.

>
> But a member function expression doesn't link the object to its member
> function. It retreives the type of the object (its class) and then
> lookup the member function. You see a relation where there is none.
>
> Let say we disagree on this point and let it at that.
>
> Let's try to catch the last ray of light of the sun on a clear sky
> above water: it is a green flash (usually on a orange sky but that's
> another story).
>
> Cheers
>

Well whatever but if you start a technical argument with me on C++ please
dont try to get reaally tchniccal as you cannot even clairfy the color of
blue sky'

 
Reply With Quote
 
 
 
 
Michael Doubez
Guest
Posts: n/a
 
      01-16-2011
On 16 jan, 17:28, Tiib <(E-Mail Removed)> wrote:
> On Jan 16, 12:50*am, Michael Doubez <(E-Mail Removed)> wrote:
>
>
>
> > On 14 jan, 21:13, Tiib <(E-Mail Removed)> wrote:

>
> > > On Jan 14, 12:11*pm, Michael Doubez <(E-Mail Removed)> wrote:

>
> > > > On 13 jan, 20:28, "Paul" <(E-Mail Removed)> wrote:

>
> > > > > An object is the concept of a data structure which consists of *member data
> > > > > and member functions. This is as much a fact as the fact that the sky is
> > > > > blue.

>
> > > > No it is not, except in vulgarisation magazines. A more precise
> > > > definition is "an object is an instance of the data structure and
> > > > behaviour defined by the object's class". You cannot make abstraction
> > > > of the class concept, otherwise, you don't have the model for the
> > > > object's state, methods and interaction; even if the class is not
> > > > expressed by the language (in some languages where functions are in
> > > > fact data members, like in javascript).

>
> > > *"A class" (like in class-based OO languages) makes no sense in
> > > Javascript.

>
> > IIRC, in javascrpit OO works on the pattern

>
> > function MyClasse(parameter1, parameter2) {
> > * * this.attribute1 = parameter1;
> > * * this.attribute2 = parameter2;

>
> > * * this.method = function() {
> > * * * * alert("Attributs: " + this.attribute1 + ", " +
> > this.attribute2);
> > * * }

>
> > }

>
> > var obj = new MyClasse("value1", "value2");
> > obj.method();

>
> > The class does exists although, like in mainy dynamic typing language,
> > it is not formalized at the language level.

>
> There is prototype, you clone that prototype with new, not create
> instances of class. You can add methods to prototype outside of that
> "contructor" like "MyClasse.prototype.otherMethod = function()
> { return 42; }" and from there on the clones have it too.
>
> > When working on the DOM of a page, you still have to lookup the
> > members and the methods available at the nodes (in fact you do look up
> > the type of the node); that is the class.

>
> No there are no classes in prototype based languages like Javascript,
> Actionscript or Lua. Static classes are good for compiled languages
> and allow simpler optimizations.


I think we should define class and its context otherwise we won't hear
one another.
When I talk about class in the OOP context, I mean the abstract
characteristics shared by all object of the class.

And I did'nt speak about static class. But when you get an object, you
must know something of the object, even inspection can give you
meaning about the object only if you have some meta-knowledge (like
duck-typing in C++).

>
> > > Class is other (less flexible) concept than that language
> > > supports. Javascript's prototypes are not classes. Objects have full
> > > freedom to change their data model and behavior during their lifetime
> > > (and may do same to other objects that they know of).

>
> > In theory, but in practice, if it they change their interface, they
> > become useless because you don't know what method you can call. I
> > won't start the dynamic typing vs static typing all over again, my
> > only point is that this feature is mainly useful at the development
> > stage, not at runtime (where a static typing language can then achieve
> > the same).

>
> I did not want to imply that more flexible is always superior or that C
> ++ is not flexible enough. However ... like you see, some template
> wizardry of C++ is used to achieve more dynamic types like
> boost::variant or more dynamic functions like with boost::bind. So
> there is a market for more run-time flexibility in C++ community.


My point here was to say that as soon as the program is finished in
the dynamic type language, you could rewrite it in static type
language. As an example, IIRC there is a ruby to C interpreter/
compiler.

In the facts, even if an object could mutate beyond recognition, you
don't do it because the program cannot deduce meaning by itself, it is
ultimately the programer that does. And the programmer does so by
having a blueprint of the object's capacity which I call (or I pretend
that they are) the class of the object.

>
> > > The objects of
> > > Javascript are not forced to stay in prototype where they started in
> > > and so they simply have no class.

>
> > They don't have to but, as I said, in practice you do.
> > As an example, in prototype.js you define classes (among other
> > things).

>
> > In fact, I don't see how you can speak about inheritance without class
> > and inheritance is (arguably) a base concept of OOP.

>
> I don't think that it is mandatory concept. In Javascript there are
> cloning of prototypes and delegation and reflection. Quite powerful
> features if to think of it. Usually when someone talks of inheritance
> as OOP concept these days then he mentions delegation as alternative.


From my point of view, inheritance is the fundamental concept of the
implementations: prototype, meta-object ... I think it depends on the
level you are talking. Prototype base language are defined as class-
less programming so I might be wrong.

Well, that's the curse of OOP, nobody agree on a definition and/or the
purpose of a feature.

--
Michael
 
Reply With Quote
 
Paul
Guest
Posts: n/a
 
      01-17-2011

"Michael Doubez" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
On 16 jan, 17:28, Tiib <(E-Mail Removed)> wrote:
> On Jan 16, 12:50 am, Michael Doubez <(E-Mail Removed)> wrote:
>
>
>
> > On 14 jan, 21:13, Tiib <(E-Mail Removed)> wrote:

>
> > > On Jan 14, 12:11 pm, Michael Doubez <(E-Mail Removed)> wrote:

>
> > > > On 13 jan, 20:28, "Paul" <(E-Mail Removed)> wrote:

>
> > > > > An object is the concept of a data structure which consists of
> > > > > member data
> > > > > and member functions. This is as much a fact as the fact that the
> > > > > sky is
> > > > > blue.

>
> > > > No it is not, except in vulgarisation magazines. A more precise
> > > > definition is "an object is an instance of the data structure and
> > > > behaviour defined by the object's class". You cannot make
> > > > abstraction
> > > > of the class concept, otherwise, you don't have the model for the
> > > > object's state, methods and interaction; even if the class is not
> > > > expressed by the language (in some languages where functions are in
> > > > fact data members, like in javascript).

>
> > > "A class" (like in class-based OO languages) makes no sense in
> > > Javascript.

>
> > IIRC, in javascrpit OO works on the pattern

>
> > function MyClasse(parameter1, parameter2) {
> > this.attribute1 = parameter1;
> > this.attribute2 = parameter2;

>
> > this.method = function() {
> > alert("Attributs: " + this.attribute1 + ", " +
> > this.attribute2);
> > }

>
> > }

>
> > var obj = new MyClasse("value1", "value2");
> > obj.method();

>
> > The class does exists although, like in mainy dynamic typing language,
> > it is not formalized at the language level.

>
> There is prototype, you clone that prototype with new, not create
> instances of class. You can add methods to prototype outside of that
> "contructor" like "MyClasse.prototype.otherMethod = function()
> { return 42; }" and from there on the clones have it too.
>
> > When working on the DOM of a page, you still have to lookup the
> > members and the methods available at the nodes (in fact you do look up
> > the type of the node); that is the class.

>
> No there are no classes in prototype based languages like Javascript,
> Actionscript or Lua. Static classes are good for compiled languages
> and allow simpler optimizations.


I think we should define class and its context otherwise we won't hear
one another.
When I talk about class in the OOP context, I mean the abstract
characteristics shared by all object of the class.

And I did'nt speak about static class. But when you get an object, you
must know something of the object, even inspection can give you
meaning about the object only if you have some meta-knowledge (like
duck-typing in C++).

>
> > > Class is other (less flexible) concept than that language
> > > supports. Javascript's prototypes are not classes. Objects have full
> > > freedom to change their data model and behavior during their lifetime
> > > (and may do same to other objects that they know of).

>
> > In theory, but in practice, if it they change their interface, they
> > become useless because you don't know what method you can call. I
> > won't start the dynamic typing vs static typing all over again, my
> > only point is that this feature is mainly useful at the development
> > stage, not at runtime (where a static typing language can then achieve
> > the same).

>
> I did not want to imply that more flexible is always superior or that C
> ++ is not flexible enough. However ... like you see, some template
> wizardry of C++ is used to achieve more dynamic types like
> boost::variant or more dynamic functions like with boost::bind. So
> there is a market for more run-time flexibility in C++ community.


My point here was to say that as soon as the program is finished in
the dynamic type language, you could rewrite it in static type
language. As an example, IIRC there is a ruby to C interpreter/
compiler.

In the facts, even if an object could mutate beyond recognition, you
don't do it because the program cannot deduce meaning by itself, it is
ultimately the programer that does. And the programmer does so by
having a blueprint of the object's capacity which I call (or I pretend
that they are) the class of the object.

>
> > > The objects of
> > > Javascript are not forced to stay in prototype where they started in
> > > and so they simply have no class.

>
> > They don't have to but, as I said, in practice you do.
> > As an example, in prototype.js you define classes (among other
> > things).

>
> > In fact, I don't see how you can speak about inheritance without class
> > and inheritance is (arguably) a base concept of OOP.

>
> I don't think that it is mandatory concept. In Javascript there are
> cloning of prototypes and delegation and reflection. Quite powerful
> features if to think of it. Usually when someone talks of inheritance
> as OOP concept these days then he mentions delegation as alternative.


From my point of view, inheritance is the fundamental concept of the
implementations: prototype, meta-object ... I think it depends on the
level you are talking. Prototype base language are defined as class-
less programming so I might be wrong.

Well, that's the curse of OOP, nobody agree on a definition and/or the
purpose of a feature.

--
.......................................

No people do agree, its just this newsgroup that do not agree with the
geneal public.

 
Reply With Quote
 
stan
Guest
Posts: n/a
 
      01-17-2011
Paul wrote:
> "Michael Doubez" <(E-Mail Removed)> wrote in message


<snip>
>> >> For this reason alone a member function is part of an object as much as
>> >> the
>> >> sky is blue.

>>
>> > Actually, it is not but I won't talk about dipole physics here

>>
>> The sky is blue, obviously in daytime( for those who choose to observe the
>> sky at night)
>> I don't know what color the sky is in your world, if not blue.

>
> I see it blue all right but I know it is composed of layers of gases
> that are not blue.
> .................................................. ........
>
> If you see it as blue thats possibly because it is blue.
> What color do you suggest it is, if not blue?


Try it this way. If I were to collect a sample of "sky" with a
satellite, balloon, or maybe a plane and bring it back to an indoor
lab, would that "sky"' be blue? In other words is the "sky" blue or
does it just appear that way? Pedantic? Sure but your stated purpose
is technical correctness, right? If that's so would you say it's more
technically correct to say the "sky is blue" or "sky appears blue
under normal daytime circumstances when viewed from Earth"

Extra credit: does the sky appear blue when viewed from the light side
of the moon?

Your arguments about c++ are equally imprecise and when viewed from
planet "C++ standard". Common usage of many terms and specifically
common use of object technology terms used in other frames of
reference have no bearing on C++ standard definition and
usage.

Standards are really hard to write and a nearly infinite list
of competing concerns come into play and the result (in almost every
standard) is a very complex and non intuitive language. Understanding
takes time, very careful reading, and open minded discussion with
others.

Like it or not, C++ defines terms independently of other object
languages and will almost certainly never change the term definitions simply
to conform to other language usage. The standards committee has that
right and no incentive to pursue foolish consistency.

I can't tell if you don't grok the terminology or the concepts. I also
can't tell why you care about this issue. You don't appear to be
implementing the language you haven't mentioned any relevant specific
example of a problem you face. The standard isn't the best document to
learn how to use the language and it's not targeted at that
purpose. The target audience is skewed towards people implementing
C++.



>> >> People can argue the sky is not blue and its only the refracted light
>> >> that
>> >> enters our eyeballs that appears to be blue. But they are wrong, the
>> >> sky
>> >> *IS* blue.


As noted above, I'd say that's not very precise language.

>>
>> > Actually the dipoles of the high atmosphere vibrate and emit all
>> > colour but inversoerse proportionnal to the power of 4 of the wave
>> > length. Thus blus is predominates.

>>
>> So the sky is blue? or blus? Make your mind up earlier you said the sky
>> wasn't blue.
>> What actually is the colour of the sky in your world?

>
> The color of difracted light.
>
> There is also the factor that our human eyes perceives some coulours
> better than other.
> '''''''''''''''''''''''''''''''''''''''''''''''''' ''''''''''''''''''''''''''''''''
>
> So answer the question.
> What is the color of the sky in your world? (during daytime)
> You seem to be unable to determine which color the sky is.


The sky has no color attribute, but maybe you had better define
precisely what you mean by "sky"

> You see a blue sky. I see difracted light. From my point of view, blue
> is not an intrinsec attribute of the sky.
> .................................................. ........
>
> But the sky *is* blue , so how come you cannot see this?


Possibly he's viewing it from the space shuttle?

>> >> The fact that a small group of people cannot understand the obvious and
>> >> misinterpet the standards by quoting out of context does not make them
>> >> correct.
>> >> Please do not be influenced by their idiotic and moronic way of
>> >> thinking.
>> >>


Have you ever met anyone who agrees with you point of view?

>> >> Because something is not covered by the C++ standards does not mean it
>> >> is
>> >> not C++. To state this suggests you do not understand what a standard
>> >> is,
>> >> or
>> >> it's intended purpose.


Perhaps you could explain the purpose of the standard?

Morons patiently standing by awaiting enlightenment.....
 
Reply With Quote
 
Michael Doubez
Guest
Posts: n/a
 
      01-17-2011
On 17 jan, 02:10, "Paul" <(E-Mail Removed)> wrote:
> "Michael Doubez" <(E-Mail Removed)> wrote in message
>
> news:(E-Mail Removed)...
> On 16 jan, 17:28, Tiib <(E-Mail Removed)> wrote:
>
>
>
> > On Jan 16, 12:50 am, Michael Doubez <(E-Mail Removed)> wrote:

>
> > > On 14 jan, 21:13, Tiib <(E-Mail Removed)> wrote:

>
> > > > On Jan 14, 12:11 pm, Michael Doubez <(E-Mail Removed)> wrote:

>
> > > > > On 13 jan, 20:28, "Paul" <(E-Mail Removed)> wrote:

>
> > > > > > An object is the concept of a data structure which consists of
> > > > > > member data
> > > > > > and member functions. This is as much a fact as the fact that the
> > > > > > sky is
> > > > > > blue.

>
> > > > > No it is not, except in vulgarisation magazines. A more precise
> > > > > definition is "an object is an instance of the data structure and
> > > > > behaviour defined by the object's class". You cannot make
> > > > > abstraction
> > > > > of the class concept, otherwise, you don't have the model for the
> > > > > object's state, methods and interaction; even if the class is not
> > > > > expressed by the language (in some languages where functions are in
> > > > > fact data members, like in javascript).

>
> > > > "A class" (like in class-based OO languages) makes no sense in
> > > > Javascript.

>
> > > IIRC, in javascrpit OO works on the pattern

>
> > > function MyClasse(parameter1, parameter2) {
> > > this.attribute1 = parameter1;
> > > this.attribute2 = parameter2;

>
> > > this.method = function() {
> > > alert("Attributs: " + this.attribute1 + ", " +
> > > this.attribute2);
> > > }

>
> > > }

>
> > > var obj = new MyClasse("value1", "value2");
> > > obj.method();

>
> > > The class does exists although, like in mainy dynamic typing language,
> > > it is not formalized at the language level.

>
> > There is prototype, you clone that prototype with new, not create
> > instances of class. You can add methods to prototype outside of that
> > "contructor" like "MyClasse.prototype.otherMethod = function()
> > { return 42; }" and from there on the clones have it too.

>
> > > When working on the DOM of a page, you still have to lookup the
> > > members and the methods available at the nodes (in fact you do look up
> > > the type of the node); that is the class.

>
> > No there are no classes in prototype based languages like Javascript,
> > Actionscript or Lua. Static classes are good for compiled languages
> > and allow simpler optimizations.

>
> I think we should define class and its context otherwise we won't hear
> one another.
> When I talk about class in the OOP context, I mean the abstract
> characteristics shared by all object of the class.
>
> And I did'nt speak about static class. But when you get an object, you
> must know something of the object, even inspection can give you
> meaning about the object only if you have some meta-knowledge (like
> duck-typing in C++).
>
>
>
>
>
> > > > Class is other (less flexible) concept than that language
> > > > supports. Javascript's prototypes are not classes. Objects have full
> > > > freedom to change their data model and behavior during their lifetime
> > > > (and may do same to other objects that they know of).

>
> > > In theory, but in practice, if it they change their interface, they
> > > become useless because you don't know what method you can call. I
> > > won't start the dynamic typing vs static typing all over again, my
> > > only point is that this feature is mainly useful at the development
> > > stage, not at runtime (where a static typing language can then achieve
> > > the same).

>
> > I did not want to imply that more flexible is always superior or that C
> > ++ is not flexible enough. However ... like you see, some template
> > wizardry of C++ is used to achieve more dynamic types like
> > boost::variant or more dynamic functions like with boost::bind. So
> > there is a market for more run-time flexibility in C++ community.

>
> My point here was to say that as soon as the program is finished in
> the dynamic type language, you could rewrite it in static type
> language. As an example, IIRC there is a ruby to C interpreter/
> compiler.
>
> In the facts, even if an object could mutate beyond recognition, you
> don't do it because the program cannot deduce meaning by itself, it is
> ultimately the programer that does. And the programmer does so by
> having a blueprint of the object's capacity which I call (or I pretend
> that they are) the class of the object.
>
>
>
>
>
> > > > The objects of
> > > > Javascript are not forced to stay in prototype where they started in
> > > > and so they simply have no class.

>
> > > They don't have to but, as I said, in practice you do.
> > > As an example, in prototype.js you define classes (among other
> > > things).

>
> > > In fact, I don't see how you can speak about inheritance without class
> > > and inheritance is (arguably) a base concept of OOP.

>
> > I don't think that it is mandatory concept. In Javascript there are
> > cloning of prototypes and delegation and reflection. Quite powerful
> > features if to think of it. Usually when someone talks of inheritance
> > as OOP concept these days then he mentions delegation as alternative.

>
> From my point of view, inheritance is the fundamental concept of the
> implementations: prototype, meta-object ... I think it depends on the
> level you are talking. Prototype base language are defined as class-
> less programming so I might be wrong.
>
> Well, that's the curse of OOP, nobody agree on a definition and/or the
> purpose of a feature.
>
> ......................................
>
> No people do agree, its just this newsgroup that do not agree with the
> geneal public.


Please, get a little more background on the subject before answering
such useless comment; this is very trollish.

As for continuing with Tib

For prototype-based/class-based languages, "A theory of objects" by
Martn Abadi and Luca Cardelli note:
<quote>
The main insight of the object-based model is that class-based notions
need not be assumed, but instead can be emulated by more primitive
notions. Moreover, these more primitive notions can be combined in
more flexible ways than a strict class discipline.[....]
</quote>

This backs my claim that that you cannot do without class (as I
understand it) but my defintion must be broader than generally
accepted since it is clearly defined as a language without class.

--
Michael
 
Reply With Quote
 
gwowen
Guest
Posts: n/a
 
      01-17-2011
On Jan 17, 9:06*am, Michael Doubez <(E-Mail Removed)> wrote:

> Please, get a little more background on the subject before answering
> such useless comment; this is very trollish.


You suspect Paul might be trollish? How very astute you are! I am in
awe of your powers of observation.
A new suggestion: reread the original suggestion in the very first
post of this thread.
 
Reply With Quote
 
Tiib
Guest
Posts: n/a
 
      01-18-2011
On Jan 17, 11:06*am, Michael Doubez <(E-Mail Removed)> wrote:
> On 17 jan, 02:10, "Paul" <(E-Mail Removed)> wrote:
>
>
>
>
>
> > "Michael Doubez" <(E-Mail Removed)> wrote in message

>
> >news:(E-Mail Removed)....
> > On 16 jan, 17:28, Tiib <(E-Mail Removed)> wrote:

>
> > > On Jan 16, 12:50 am, Michael Doubez <(E-Mail Removed)> wrote:

>
> > > > On 14 jan, 21:13, Tiib <(E-Mail Removed)> wrote:

>
> > > > > On Jan 14, 12:11 pm, Michael Doubez <(E-Mail Removed)> wrote:

>
> > > > > > On 13 jan, 20:28, "Paul" <(E-Mail Removed)> wrote:

>
> > > > > > > An object is the concept of a data structure which consists of
> > > > > > > member data
> > > > > > > and member functions. This is as much a fact as the fact that the
> > > > > > > sky is
> > > > > > > blue.

>
> > > > > > No it is not, except in vulgarisation magazines. A more precise
> > > > > > definition is "an object is an instance of the data structure and
> > > > > > behaviour defined by the object's class". You cannot make
> > > > > > abstraction
> > > > > > of the class concept, otherwise, you don't have the model for the
> > > > > > object's state, methods and interaction; even if the class is not
> > > > > > expressed by the language (in some languages where functions are in
> > > > > > fact data members, like in javascript).

>
> > > > > "A class" (like in class-based OO languages) makes no sense in
> > > > > Javascript.

>
> > > > IIRC, in javascrpit OO works on the pattern

>
> > > > function MyClasse(parameter1, parameter2) {
> > > > this.attribute1 = parameter1;
> > > > this.attribute2 = parameter2;

>
> > > > this.method = function() {
> > > > alert("Attributs: " + this.attribute1 + ", " +
> > > > this.attribute2);
> > > > }

>
> > > > }

>
> > > > var obj = new MyClasse("value1", "value2");
> > > > obj.method();

>
> > > > The class does exists although, like in mainy dynamic typing language,
> > > > it is not formalized at the language level.

>
> > > There is prototype, you clone that prototype with new, not create
> > > instances of class. You can add methods to prototype outside of that
> > > "contructor" like "MyClasse.prototype.otherMethod = function()
> > > { return 42; }" and from there on the clones have it too.

>
> > > > When working on the DOM of a page, you still have to lookup the
> > > > members and the methods available at the nodes (in fact you do look up
> > > > the type of the node); that is the class.

>
> > > No there are no classes in prototype based languages like Javascript,
> > > Actionscript or Lua. Static classes are good for compiled languages
> > > and allow simpler optimizations.

>
> > I think we should define class and its context otherwise we won't hear
> > one another.
> > When I talk about class in the OOP context, I mean the abstract
> > characteristics shared by all object of the class.

>
> > And I did'nt speak about static class. But when you get an object, you
> > must know something of the object, even inspection can give you
> > meaning about the object only if you have some meta-knowledge (like
> > duck-typing in C++).

>
> > > > > Class is other (less flexible) concept than that language
> > > > > supports. Javascript's prototypes are not classes. Objects have full
> > > > > freedom to change their data model and behavior during their lifetime
> > > > > (and may do same to other objects that they know of).

>
> > > > In theory, but in practice, if it they change their interface, they
> > > > become useless because you don't know what method you can call. I
> > > > won't start the dynamic typing vs static typing all over again, my
> > > > only point is that this feature is mainly useful at the development
> > > > stage, not at runtime (where a static typing language can then achieve
> > > > the same).

>
> > > I did not want to imply that more flexible is always superior or that C
> > > ++ is not flexible enough. However ... like you see, some template
> > > wizardry of C++ is used to achieve more dynamic types like
> > > boost::variant or more dynamic functions like with boost::bind. So
> > > there is a market for more run-time flexibility in C++ community.

>
> > My point here was to say that as soon as the program is finished in
> > the dynamic type language, you could rewrite it in static type
> > language. As an example, IIRC there is a ruby to C interpreter/
> > compiler.

>
> > In the facts, even if an object could mutate beyond recognition, you
> > don't do it because the program cannot deduce meaning by itself, it is
> > ultimately the programer that does. And the programmer does so by
> > having a blueprint of the object's capacity which I call (or I pretend
> > that they are) the class of the object.

>
> > > > > The objects of
> > > > > Javascript are not forced to stay in prototype where they started in
> > > > > and so they simply have no class.

>
> > > > They don't have to but, as I said, in practice you do.
> > > > As an example, in prototype.js you define classes (among other
> > > > things).

>
> > > > In fact, I don't see how you can speak about inheritance without class
> > > > and inheritance is (arguably) a base concept of OOP.

>
> > > I don't think that it is mandatory concept. In Javascript there are
> > > cloning of prototypes and delegation and reflection. Quite powerful
> > > features if to think of it. Usually when someone talks of inheritance
> > > as OOP concept these days then he mentions delegation as alternative.

>
> > From my point of view, inheritance is the fundamental concept of the
> > implementations: prototype, meta-object ... I think it depends on the
> > level you are talking. Prototype base language are defined as class-
> > less programming so I might be wrong.

>
> > Well, that's the curse of OOP, nobody agree on a definition and/or the
> > purpose of a feature.

>
> > ......................................

>
> > No people do agree, its just this newsgroup that do not agree with the
> > geneal public.

>
> Please, get a little more background on the subject before answering
> such useless comment; this is very trollish.
>
> As for continuing with Tib
>
> For prototype-based/class-based languages, "A theory of objects" by
> Martn Abadi and Luca Cardelli note:
> <quote>
> The main insight of the object-based model is that class-based notions
> need not be assumed, but instead can be emulated by more primitive
> notions. Moreover, these more primitive notions can be combined in
> more flexible ways than a strict class discipline.[....]
> </quote>
>
> This backs my claim that that you cannot do without class (as I
> understand it) but my defintion must be broader than generally
> accepted since it is clearly defined as a language without class.


Yes, perhaps you imagine classes differently than on common case.
Commonly a class is fixed template. A type that is sort of self-
contained and does not change for particular object. There are
inheritance hierarchies of classes to gain some flexibility with fixed
set of "reasonable" combinations. On most cases it is good enough.

The prototypes are more flexible than classes. Objects can gain and
change their abilities and attributes during their life-time. Objects
interfaces (and amount of available interfaces) may change
dynamically. That makes prototype-based objects more life-like. More
flexibility may make it more complex, but like your book say that
class-like behavior may be always emulated where it is good enough.

For simple example ... a door. It does not make sense to lock (or
unlock) it when it lacks locks. Either there is always an interface
that does not make sense for all doors or ... if it initially did not
have locks then you have to "destroy" the lockless door and
"construct" new one with lock to add a lock to door.
 
Reply With Quote
 
Michael Doubez
Guest
Posts: n/a
 
      01-18-2011
On 18 jan, 01:33, Tiib <(E-Mail Removed)> wrote:
> On Jan 17, 11:06*am, Michael Doubez <(E-Mail Removed)> wrote:
>
>
>
> > On 17 jan, 02:10, "Paul" <(E-Mail Removed)> wrote:

>
> > > "Michael Doubez" <(E-Mail Removed)> wrote in message

>
> > >news:(E-Mail Removed)....
> > > On 16 jan, 17:28, Tiib <(E-Mail Removed)> wrote:

>
> > > > On Jan 16, 12:50 am, Michael Doubez <(E-Mail Removed)> wrote:

>
> > > > > On 14 jan, 21:13, Tiib <(E-Mail Removed)> wrote:

>
> > > > > > On Jan 14, 12:11 pm, Michael Doubez <(E-Mail Removed)> wrote:

>
> > > > > > > On 13 jan, 20:28, "Paul" <(E-Mail Removed)> wrote:

>
> > > > > > > > An object is the concept of a data structure which consists of
> > > > > > > > member data
> > > > > > > > and member functions. This is as much a fact as the fact that the
> > > > > > > > sky is
> > > > > > > > blue.

>
> > > > > > > No it is not, except in vulgarisation magazines. A more precise
> > > > > > > definition is "an object is an instance of the data structure and
> > > > > > > behaviour defined by the object's class". You cannot make
> > > > > > > abstraction
> > > > > > > of the class concept, otherwise, you don't have the model for the
> > > > > > > object's state, methods and interaction; even if the class is not
> > > > > > > expressed by the language (in some languages where functions are in
> > > > > > > fact data members, like in javascript).

>
> > > > > > "A class" (like in class-based OO languages) makes no sense in
> > > > > > Javascript.

>
> > > > > IIRC, in javascrpit OO works on the pattern

>
> > > > > function MyClasse(parameter1, parameter2) {
> > > > > this.attribute1 = parameter1;
> > > > > this.attribute2 = parameter2;

>
> > > > > this.method = function() {
> > > > > alert("Attributs: " + this.attribute1 + ", " +
> > > > > this.attribute2);
> > > > > }

>
> > > > > }

>
> > > > > var obj = new MyClasse("value1", "value2");
> > > > > obj.method();

>
> > > > > The class does exists although, like in mainy dynamic typing language,
> > > > > it is not formalized at the language level.

>
> > > > There is prototype, you clone that prototype with new, not create
> > > > instances of class. You can add methods to prototype outside of that
> > > > "contructor" like "MyClasse.prototype.otherMethod = function()
> > > > { return 42; }" and from there on the clones have it too.

>
> > > > > When working on the DOM of a page, you still have to lookup the
> > > > > members and the methods available at the nodes (in fact you do look up
> > > > > the type of the node); that is the class.

>
> > > > No there are no classes in prototype based languages like Javascript,
> > > > Actionscript or Lua. Static classes are good for compiled languages
> > > > and allow simpler optimizations.

>
> > > I think we should define class and its context otherwise we won't hear
> > > one another.
> > > When I talk about class in the OOP context, I mean the abstract
> > > characteristics shared by all object of the class.

>
> > > And I did'nt speak about static class. But when you get an object, you
> > > must know something of the object, even inspection can give you
> > > meaning about the object only if you have some meta-knowledge (like
> > > duck-typing in C++).

>
> > > > > > Class is other (less flexible) concept than that language
> > > > > > supports. Javascript's prototypes are not classes. Objects have full
> > > > > > freedom to change their data model and behavior during their lifetime
> > > > > > (and may do same to other objects that they know of).

>
> > > > > In theory, but in practice, if it they change their interface, they
> > > > > become useless because you don't know what method you can call. I
> > > > > won't start the dynamic typing vs static typing all over again, my
> > > > > only point is that this feature is mainly useful at the development
> > > > > stage, not at runtime (where a static typing language can then achieve
> > > > > the same).

>
> > > > I did not want to imply that more flexible is always superior or that C
> > > > ++ is not flexible enough. However ... like you see, some template
> > > > wizardry of C++ is used to achieve more dynamic types like
> > > > boost::variant or more dynamic functions like with boost::bind. So
> > > > there is a market for more run-time flexibility in C++ community.

>
> > > My point here was to say that as soon as the program is finished in
> > > the dynamic type language, you could rewrite it in static type
> > > language. As an example, IIRC there is a ruby to C interpreter/
> > > compiler.

>
> > > In the facts, even if an object could mutate beyond recognition, you
> > > don't do it because the program cannot deduce meaning by itself, it is
> > > ultimately the programer that does. And the programmer does so by
> > > having a blueprint of the object's capacity which I call (or I pretend
> > > that they are) the class of the object.

>
> > > > > > The objects of
> > > > > > Javascript are not forced to stay in prototype where they started in
> > > > > > and so they simply have no class.

>
> > > > > They don't have to but, as I said, in practice you do.
> > > > > As an example, in prototype.js you define classes (among other
> > > > > things).

>
> > > > > In fact, I don't see how you can speak about inheritance without class
> > > > > and inheritance is (arguably) a base concept of OOP.

>
> > > > I don't think that it is mandatory concept. In Javascript there are
> > > > cloning of prototypes and delegation and reflection. Quite powerful
> > > > features if to think of it. Usually when someone talks of inheritance
> > > > as OOP concept these days then he mentions delegation as alternative.

>
> > > From my point of view, inheritance is the fundamental concept of the
> > > implementations: prototype, meta-object ... I think it depends on the
> > > level you are talking. Prototype base language are defined as class-
> > > less programming so I might be wrong.

>
> > > Well, that's the curse of OOP, nobody agree on a definition and/or the
> > > purpose of a feature.

>
> > > ......................................

>
> > > No people do agree, its just this newsgroup that do not agree with the
> > > geneal public.

>
> > Please, get a little more background on the subject before answering
> > such useless comment; this is very trollish.

>
> > As for continuing with Tib

>
> > For prototype-based/class-based languages, "A theory of objects" by
> > Martn Abadi and Luca Cardelli note:
> > <quote>
> > The main insight of the object-based model is that class-based notions
> > need not be assumed, but instead can be emulated by more primitive
> > notions. Moreover, these more primitive notions can be combined in
> > more flexible ways than a strict class discipline.[....]
> > </quote>

>
> > This backs my claim that that you cannot do without class (as I
> > understand it) but my defintion must be broader than generally
> > accepted since it is clearly defined as a language without class.

>
> Yes, perhaps you imagine classes differently than on common case.
> Commonly a class is fixed template. A type that is sort of self-
> contained and does not change for particular object. There are
> inheritance hierarchies of classes to gain some flexibility with fixed
> set of "reasonable" combinations. On most cases it is good enough.
>
> The prototypes are more flexible than classes. Objects can gain and
> change their abilities and attributes during their life-time. Objects
> interfaces (and amount of available interfaces) may change
> dynamically. That makes prototype-based objects more life-like. More
> flexibility may make it more complex, but like your book say that
> class-like behavior may be always emulated where it is good enough.
>
> For simple example ... a door. It does not make sense to lock (or
> unlock) it when it lacks locks. Either there is always an interface
> that does not make sense for all doors or ... if it initially did not
> have locks then you have to "destroy" the lockless door and
> "construct" new one with lock to add a lock to door.


Ok. I stand corrected.

--
Michael
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Wireless Access Point Suggestion =?Utf-8?B?UyBMYW5l?= Wireless Networking 2 06-24-2005 10:39 PM
Suggestion for a new name, logo and slogan for the Mozilla Suite... Charles Firefox 2 03-12-2005 04:31 AM
"Read-only" version of Mozilla? (suggestion for a new software idea) Hallvard Tangeraas Firefox 4 01-12-2005 07:24 PM
FireFox-opening new tabs, a suggestion me Firefox 3 09-21-2004 04:19 PM
Re: Suggestion for Cache flush in Moz Caffeine Junkie Firefox 1 01-20-2004 06:06 AM



Advertisments