A suggestion
Keith Thompson
If everyone stopped replying to him, he just might stop posting.
Or maybe he wouldn't, but that problem is easily solved by the use
of a killfile.
How likely is it that the *next* followup will be the one that
makes him change his mind, hmm?
--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Dombo
> Most of "Paul"'s postings here are followups.
>
> If everyone stopped replying to him, he just might stop posting.
>
> Or maybe he wouldn't, but that problem is easily solved by the use
> of a killfile.
>
> How likely is it that the *next* followup will be the one that
> makes him change his mind, hmm?
Frankly I'm a bit surprised that otherwise intelligent people keep
arguing with him, while it is obvious from his first few postings that
will lead to nowhere.
Paavo Helde
@news.tiscali.nl:
I'm sure they enjoyed it. It was a nice opportunity to demonstrate ones'
own invincible logic... and to re-demonstrate it - and again and again!
I think Paul hoped that some people are fool enough to support him. He
was much nicer to the responders who showed even minor understanding to
his ideas. Maybe he was hoping to tear the group into parties all
fighting each other.
Probably he now goes away to some arts/philosophy or politics group. I
predict he will have much more success there!
Cheers
Paavo
red floyd
>> Frankly I'm a bit surprised that otherwise intelligent people keep
>> arguing with him, while it is obvious from his first few postings that
>> will lead to nowhere.
>
> I'm sure they enjoyed it. It was a nice opportunity to demonstrate ones'
> own invincible logic... and to re-demonstrate it - and again and again!
>
Francis Glassborow
:)
gwowen
> How likely is it that the *next* followup will be the one that
> makes him change his mind, hmm?
Well said.
Here's what I try to do: whenever I see someone like Paul trolling on
the internet, I try and go out and use that energy I might otherwise
have spent arguing pointlessly, to do something nice for someone else,
preferably away from my computer -- donate to a worthy cause, make a
loved one a cup of tea, do the ironing... it doesn't matter. But it
might turn internet trolling into a net force for good in the
universe.
There, that's my hippy twaddle for the day.
Joshua Maurice
Too true, too true.
Öö Tiib
> Dombo <do...@disposable.invalid> wrote in news:4d299005$0$30705$5fc3050
> @news.tiscali.nl:
>
> > Op 09-Jan-11 11:07, Keith Thompson schreef:
> >> Most of "Paul"'s postings here are followups.
>
> >> If everyone stopped replying to him, he just might stop posting.
>
> >> Or maybe he wouldn't, but that problem is easily solved by the use
> >> of a killfile.
>
> >> How likely is it that the *next* followup will be the one that
> >> makes him change his mind, hmm?
>
> > Frankly I'm a bit surprised that otherwise intelligent people keep
> > arguing with him, while it is obvious from his first few postings that
> > will lead to nowhere.
>
> I'm sure they enjoyed it. It was a nice opportunity to demonstrate ones'
> own invincible logic... and to re-demonstrate it - and again and again!
Was fun to read at first how everybody were classified totally
incorrect, confused and stupid. Sadly the subject was too simple and
so it was getting repetitive and boring quick.
> I think Paul hoped that some people are fool enough to support him. He
> was much nicer to the responders who showed even minor understanding to
> his ideas. Maybe he was hoping to tear the group into parties all
> fighting each other.
Maybe. Usually they pick something more dim for such purpose.
Something about threads, exceptions, character encodings, signedness,
programming patterns, garbage collection or the like.
Joshua Maurice
Dunno. I think I was Paul recently in a thread on comp.lang.c
recently, being unkind to apparently renowned experts in an argument
over the appropriate definition of "to define a type". Unlike Paul at
least, I could see the other side's case. (I simply disagreed.) Remind
me never to do that again.
Stuart Redmann
> >> Most of "Paul"'s postings here are followups.
>
> >> If everyone stopped replying to him, he just might
> >> stop posting.
>
> >> Or maybe he wouldn't, but that problem is easily
> >> solved by the use of a killfile.
>
> >> How likely is it that the *next* followup will
> >> be the one that makes him change his mind, hmm?
Dombo wrote:
> > Frankly I'm a bit surprised that otherwise intelligent
> > people keep arguing with him, while it is obvious
> > from his first few postings that
> > will lead to nowhere.
Paavo Helde wrote:
> I'm sure they enjoyed it. It was a nice opportunity to demonstrate
> ones' own invincible logic... and to re-demonstrate it - and
> again and again!
Once I had a discussion with the famous Mr. Newcomer in
microsoft.public.vc.mfc where we came to the topic of OCD (obsessive-
compulsive disorder). I hold the believe that the percentage of
programmers that suffer from OCD is increased with regard to the mean
percentage. I think that programming requires a high degree of
strictness in order to get the computer to do what he wants him to do
(in contrast to a conversation with a human being, where one can be a
lot more imprecise).
When I see Paul's postings I get the feeling that he is quite
emotionally involved while at the same time he is open to arguments.
This looks very much like OCD to me (although I am by no means a
psychologist), and this would explain why he persists in arguing.
Regards,
Stuart
Stuart Redmann
> Dunno. I think I was Paul recently in a thread on comp.lang.c
> recently, being unkind to apparently renowned experts in an argument
> over the appropriate definition of "to define a type". Unlike Paul at
> least, I could see the other side's case. (I simply disagreed.) Remind
> me never to do that again.
Gosh, we may even end up establishing a new proverb in this newsgroup:
Don't you Paul me!
Regards,
Stuart
Paul
"Stuart Redmann" <DerT...@web.de> wrote in message
news:376e9651-a650-453e...@l32g2000yqc.googlegroups.com...
Stuart Redmann
"Stuart Redmann" wrote:
> > When I see Paul's postings I get the feeling that he is quite
> > emotionally involved while at the same time he is open to arguments.
> > This looks very much like OCD to me (although I am by no means a
> > psychologist), and this would explain why he persists in arguing.
>
> > Regards,
> > Stuart
On 12 Jan., "Paul" wrote:
> WRONG!
Would you help us to understand the driving power behind your latest
postings? Do you want to get the C++ Standard corrected because you
think that it is misleading?
Regards,
Stuart
Paul
As per the standards a big part of the problem *here* is the way in which
people attempt to quote the standards word for word often out of context
and/or misinterpreting.
The way we speak about programming is not in the same as the the C++
standards. And some reasonable level of intelligence must often be used when
reading the standards to understand what they mean in their context.
Put basically , the context of the standards is not the primary context
here, as some people often incorrectly state.
Often terms like
a) C++ has no knowledge of that
b) This is off topic here because the C++ standards do not cover it.
c) you are using a term in a different context form the C++ standards
therefore you are wrong.
d) the rules of this newsgroup are....
etc etc
are used, when that is simply rubbish. To suggest that is actually wrong and
its some kind of double negative.
I was one told that I was wrong for using ASCII in this forum, because the
C++ didn't cover it. What kind of narrow minded nonsense is that and what
will it ever achieve, except some persons ego to be boosted from correcting
another.
That kind of attitude displays a very limited imagination to me and it
frankly pretty dull and boring.
Anyway this *IS* a troll thread and I never started it so toodle pip. :)
Stuart Redmann
> > Would you help us to understand the driving power behind your latest
> > postings? Do you want to get the C++ Standard corrected because you
> > think that it is misleading?
On 12 Jan., "Paul" wrote:
> As per the standards a big part of the problem *here* is the way
> in which people attempt to quote the standards word for word often
> out of context and/or misinterpreting.
>
> The way we speak about programming is not in the same as the
> the C++ standards. And some reasonable level of intelligence must
> often be used when reading the standards to understand what they
> mean in their context.
> Put basically , the context of the standards is not the primary context
> here, as some people often incorrectly state.
The snippets of the standard that have been cited this far in various
postings make me shiver, it is quite apparently laywer-speak.
Personally, I use C++ for more than 10 years, and I only had to ask
once or twice whether something is according to the standard or not (I
don't even own a copy of it).
This does not mean that I think that the people who work on the
standard do useless work (maybe badly written, but not useless). I
think that these people who work at the standard will react quite
harsh when somebody posts here not using the vocabulary of the
standard. That is something that I can ignore quite well (having to
work with dozens of physicists every day makes one quite immune to
lacking social skills ;-)
> Often terms like
> a) C++ has no knowledge of that
> b) This is off topic here because the C++ standards do not cover it.
> c) you are using a term in a different context form the C++ standards
> therefore you are wrong.
> d) the rules of this newsgroup are....
> etc etc
> are used, when that is simply rubbish. To suggest that is actually wrong and
> its some kind of double negative.
Yeah, I know what you mean. I think that this newsgroup should not
dedicate to standard-compliant coding only, but a lot of the "key
users" think otherwise. Since I have not been criticised for posting
platform dependent code yet, I think that I am tolerated.
> I was one told that I was wrong for using ASCII in this forum, because the
> C++ didn't cover it. What kind of narrow minded nonsense is that and what
> will it ever achieve, except some persons ego to be boosted from correcting
> another.
>
> That kind of attitude displays a very limited imagination to me and it
> frankly pretty dull and boring.
Maybe because *they* have a streak of OCD in them. Maybe the usenet
serves as a kind of substitute for a peer group for these people, so
they think that they will get credit for their contributions even if
the contribution is only a rebuke. Who knows.
Regards,
Stuart
Stuart Redmann
("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).
This would mean that the compiler had to use some form of dispatch
mechanism for non-virtual member functions, too. I know that no C++
compiler provides such a mechanism, but the C++ standard doesn't
forbid it to do so.
Regards,
Stuart
Michael Doubez
> 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.
> This would mean that the compiler had to use some form of dispatch
> mechanism for non-virtual member functions, too. I know that no C++
> compiler provides such a mechanism, but the C++ standard doesn't
> forbid it to do so.
AFAIS this would be some kind of dynamic/multiple instance linkage
which is not covered by the C++ standard. This is no longer C++.
--
Michael
Paul
"Michael Doubez" <michael...@free.fr> wrote in message
news:8063b8f2-2170-40d2...@k30g2000vbn.googlegroups.com...
> On 13 jan, 13:12, Stuart Redmann <DerTop...@web.de> 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.
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.
For this reason alone a member function is part of an object as much as the
sky is blue.
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 bollocks.
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.
People can argue that a member function is not part of an object because the
opcode of the function is not actually stored inside the object. But they
are wrong because an object *does* contain functions.
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.
:)
>
>> This would mean that the compiler had to use some form of dispatch
>> mechanism for non-virtual member functions, too. I know that no C++
>> compiler provides such a mechanism, but the C++ standard doesn't
>> forbid it to do so.
>
> AFAIS this would be some kind of dynamic/multiple instance linkage
> which is not covered by the C++ standard. This is no longer C++.
>
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.
Stuart Redmann
[snip]
> > This would mean that the compiler had to use some form of dispatch
> > mechanism for non-virtual member functions, too. I know that no C++
> > compiler provides such a mechanism, but the C++ standard doesn't
> > forbid it to do so.
On 13 Jan., Michael Doubez wrote:
> AFAIS this would be some kind of dynamic/multiple instance linkage
> which is not covered by the C++ standard. This is no longer C++.
The question is whether the C++ standard does not cover it or whether
it makes some statements that would actually forbid such a feature. As
I don't have a copy of the standard I have to rely on the kindness of
others who can look this up for me.
Regards,
Stuart
Michael Doubez
> "Michael Doubez" <michael.dou...@free.fr> wrote in message
>
> news:8063b8f2-2170-40d2...@k30g2000vbn.googlegroups.com...
>
>
>
> > On 13 jan, 13:12, Stuart Redmann <DerTop...@web.de> 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).
> 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 :)
> 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 bollocks.
The first name of C++ (1979) was C With class
See http://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>
And commenting code from 1980
<quote>
Clearly, the most important aspect of C with Classes - and later of C+
+ - was the class concept.
Many aspects of the C with Classes class concept can be observed by
examining a simple example
from [Stroustrup,1980a]:
class stack {
char s[SIZE]; /* array of characters */
char * min; /* pointer to bottom of stack */
char * top; /* pointer to top of stack */
char * max; /* pointer to top of allocated space */
void new(); /* initialization function (constructor) */
public:
void push(char);
char pop();
};
A class is a user-d efined data type. A class specifies the type of
the class members that define the
representation of a variable of the type (an object of the class),
specifies the set of operations
(functions) that manipulate such objects, and specifies the access
users have to these members.
Member functions are typically defined ''elsewhere:''
</quote>
That's pretty explicit. I won't quote the wholde document and I engage
you to read it.
>
> 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.
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.
> People can argue that a member function is not part of an object because the
> opcode of the function is not actually stored inside the object. But they
> are wrong because an object *does* contain functions.
In the conext of C++, functions are member in the same sense as
someone is the member of a club. Being a member of a clud does't me
the club contains you. They are the privileged function that can
access all members and even can use the this keyword in their
definition.
> 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.
> :)
Repeating something like a psittacidea doesn't make it true.
>
> >> This would mean that the compiler had to use some form of dispatch
> >> mechanism for non-virtual member functions, too. I know that no C++
> >> compiler provides such a mechanism, but the C++ standard doesn't
> >> forbid it to do so.
>
> > AFAIS this would be some kind of dynamic/multiple instance linkage
> > which is not covered by the C++ standard. This is no longer C++.
>
> 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.
Something not in the standard of the C++ language is by definition no
longer standard C++ and since it is the only authoritative document on
a language called c++, it is no longer C++.
--
Michael
Francis Glassborow
C++ has something called 'the one definition rule' which requires that
non-inline functions (whether member functions or free functions) have
effectively at most one definition in the entirety of the code for a
program.
It is perfectly possible for every object in a program to have its own
unique set of functions but in that case every object also has to have
its own unique type.
Data types in C++ have associated behaviour. When those are class types
the behaviour is provided by member and friend functions. The difference
between those functions and all other functions is that they define
behaviour for instances of the class. However from the perspective of
functions rather than data, member functions are no different to any
other function, they have parameter lists that must be satisfied at call
time by suitable arguments. The special calling syntax for member
functions is nothing more than some syntactic sugar. Like many cases of
syntactic sugar it is helpful to programmers but not to implementations
(they have to work that much harder to support the feature)
In case it is still unclear, yes the C++ Standard does implicitly ban
alternative (per object) definitions. This is even true for virtual
functions, once you know the actual type of an object their is a single
unique definition of its behaviour (as provided by its type's member
functions and friend functions). Virtual (late binding) behaviour only
occurs when the actual type is not known at compile time because a
reference or pointer is being used.
Stuart Redmann
> > The question is whether the C++ standard does not cover it or whether
> > it makes some statements that would actually forbid such a
On 14 Jan., Francis Glassborow wrote:
> C++ has something called 'the one definition rule' which requires that
> non-inline functions (whether member functions or free functions) have
> effectively at most one definition in the entirety of the code for a
> program.
I was not intending to violate the ODR. What I wanted to achieve is
that the run-time would create copies of the member function, quite
similar to the Unix fork command using the copy-on-write semantics of
the paging system. Effectively, each object would get the same
implementation of the member function. Only when an object decides to
manipulate its own member function, the run-time would provide a
separate copy.
> It is perfectly possible for every object in a program to have its own
> unique set of functions but in that case every object also has to have
> its own unique type.
The last paragraph is (hopefully) meant with regard to the the C++
object model.
> Data types in C++ have associated behaviour. When those are class types
> the behaviour is provided by member and friend functions. The difference
> between those functions and all other functions is that they define
> behaviour for instances of the class. However from the perspective of
> functions rather than data, member functions are no different to any
> other function, they have parameter lists that must be satisfied at call
> time by suitable arguments. The special calling syntax for member
> functions is nothing more than some syntactic sugar. Like many cases of
> syntactic sugar it is helpful to programmers but not to implementations
> (they have to work that much harder to support the feature)
>
> In case it is still unclear, yes the C++ Standard does implicitly ban
> alternative (per object) definitions.
Thanks for the clarification.
Regards,
Stuart
Paul
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.
>> 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 bollocks.
>
> The first name of C++ (1979) was C With class
> See http://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.
What are you supposed to be proving with this quote?
Again , are you suggesting C++ does not support OOP?
>>
>> 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.
>
> 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?
>> People can argue that a member function is not part of an object because
>> the
>> opcode of the function is not actually stored inside the object. But they
>> are wrong because an object *does* contain functions.
>
> In the conext of C++, functions are member in the same sense as
> someone is the member of a club. Being a member of a clud does't me
> the club contains you. They are the privileged function that can
> access all members and even can use the this keyword in their
> definition.
>
If you are a member of something you belong to it , or are part of it,
associated with it . Whatever term you use it just seems like pernickety
pedantic babbling to argue against this general meaning.
>> 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.
>> :)
>
> Repeating something like a psittacidea doesn't make it true.
>
Are you suggesting something is untrue? If so what?
>>
>> >> This would mean that the compiler had to use some form of dispatch
>> >> mechanism for non-virtual member functions, too. I know that no C++
>> >> compiler provides such a mechanism, but the C++ standard doesn't
>> >> forbid it to do so.
>>
>> > AFAIS this would be some kind of dynamic/multiple instance linkage
>> > which is not covered by the C++ standard. This is no longer C++.
>>
>> 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.
>
> Something not in the standard of the C++ language is by definition no
> longer standard C++ and since it is the only authoritative document on
> a language called c++, it is no longer C++.
>
Because sometihng is UB or IS does not mean it is no longer C++, thats pure
bollocks.
You are another person who doesnt seem to understand what a standard is or
its purpose.
Note: I apologise if I offend anyone with use of the vulgar word bollocks.
I'm sure Michael will not be offended if he reads those sort of magazines.
:)
Öö Tiib
> On 13 jan, 20:28, "Paul" <pchris...@yahoo.co.uk> 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. 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). The objects of
Javascript are not forced to stay in prototype where they started in
and so they simply have no class.
Michael Doubez
> On Jan 14, 12:11 pm, Michael Doubez <michael.dou...@free.fr> wrote:
>
> > On 13 jan, 20:28, "Paul" <pchris...@yahoo.co.uk> 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.
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.
> 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).
> 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.
Actually, in the implementation, you can work with objects (like in
smalltalk where you can change base of an object, and I suspect
prototype.js does the same) but IMHO metaobjects are just an
implementation of classes.
--
Michael
Michael Doubez
I see it blue all right but I know it is composed of layers of gases
that are not blue.
> >> 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 bollocks.
>
> > 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.
It does not support *your* definition of OOP.
> >> 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.
>
> > 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.
> >> People can argue that a member function is not part of an object because
> >> the
> >> opcode of the function is not actually stored inside the object. But they
> >> are wrong because an object *does* contain functions.
>
> > In the conext of C++, functions are member in the same sense as
> > someone is the member of a club. Being a member of a clud does't me
> > the club contains you. They are the privileged function that can
> > access all members and even can use the this keyword in their
> > definition.
>
> If you are a member of something you belong to it , or are part of it,
> associated with it . Whatever term you use it just seems like pernickety
> pedantic babbling to argue against this general meaning.
You see a blue sky. I see difracted light. From my point of view, blue
is not an intrinsec attribute of the sky.
> >> 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.
> >> :)
>
> > Repeating something like a psittacidea doesn't make it true.
>
> Are you suggesting something is untrue? If so what?
Are you suggesting something is true? If so what?
> >> >> This would mean that the compiler had to use some form of dispatch
> >> >> mechanism for non-virtual member functions, too. I know that no C++
> >> >> compiler provides such a mechanism, but the C++ standard doesn't
> >> >> forbid it to do so.
>
> >> > AFAIS this would be some kind of dynamic/multiple instance linkage
> >> > which is not covered by the C++ standard. This is no longer C++.
>
> >> 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.
>
> > Something not in the standard of the C++ language is by definition no
> > longer standard C++ and since it is the only authoritative document on
> > a language called c++, it is no longer C++.
>
> Because sometihng is UB or IS does not mean it is no longer C++, thats pure
> bollocks.
If something is UB, it is noted as such in the standard.
> You are another person who doesnt seem to understand what a standard is or
> its purpose.
>
> Note: I apologise if I offend anyone with use of the vulgar word bollocks.
> I'm sure Michael will not be offended if he reads those sort of magazines.
> :)
I am not a native english speaker. Those words have no emotional
weight for me even if I understand them.
--
Michael
Paul
..........................................................
If you see it as blue thats possibly because it is blue.
What color do you suggest it is, if not blue?
> >> 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
> >> bollocks.
>
> > 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.
.............................................................
C++ does support my idea of OOP, the fact that C++ provides member
functions, inheretence , encapsulation and polymorphism is enough to suggest
C++ supports OOP.
What is your idea of OOP? It's seems that your idea of OOP is that an object
is a simple region of storage and nothing more.
> >> 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.
>
> > 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.
> >> People can argue that a member function is not part of an object
> >> because
> >> the
> >> opcode of the function is not actually stored inside the object. But
> >> they
> >> are wrong because an object *does* contain functions.
>
> > In the conext of C++, functions are member in the same sense as
> > someone is the member of a club. Being a member of a clud does't me
> > the club contains you. They are the privileged function that can
> > access all members and even can use the this keyword in their
> > definition.
>
> If you are a member of something you belong to it , or are part of it,
> associated with it . Whatever term you use it just seems like pernickety
> pedantic babbling to argue against this general meaning.
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?
> >> 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.
> >> :)
>
> > Repeating something like a psittacidea doesn't make it true.
>
> Are you suggesting something is untrue? If so what?
Are you suggesting something is true? If so what?
.....................................................
It was you who made the statement I commented on re:
"Repeating something like a psittacidea doesn't make it true."
It was unclear what you were suggesting with this statement. Now it's
apparent you either didn't/don't know what you were talking about or you are
deliberately trying to introduce confusion.
> >> >> This would mean that the compiler had to use some form of dispatch
> >> >> mechanism for non-virtual member functions, too. I know that no C++
> >> >> compiler provides such a mechanism, but the C++ standard doesn't
> >> >> forbid it to do so.
>
> >> > AFAIS this would be some kind of dynamic/multiple instance linkage
> >> > which is not covered by the C++ standard. This is no longer C++.
>
> >> 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.
>
> > Something not in the standard of the C++ language is by definition no
> > longer standard C++ and since it is the only authoritative document on
> > a language called c++, it is no longer C++.
>
> Because sometihng is UB or IS does not mean it is no longer C++, thats
> pure
> bollocks.
If something is UB, it is noted as such in the standard.
.....................................................................
If something is undefined behaviour the it is *undefined*. This does not
mean it is not valid C++, as is the case with implementation specific C++
> You are another person who doesnt seem to understand what a standard is or
> its purpose.
>
> Note: I apologise if I offend anyone with use of the vulgar word bollocks.
> I'm sure Michael will not be offended if he reads those sort of magazines.
> :)
I am not a native english speaker. Those words have no emotional
weight for me even if I understand them.
......................................
Well that explains alot.
FYI the term you used ref "vulgarisation magazine" would generally be
considered to mean a pornography magazine.
Paul
.................................................................
I see where you are coming from in associating this with a C++ class but
this is not the case in Javascript.
In Javascript all objects are created from a simple built-in Object.
...............................................................
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.
................................................................
IIRC a DOM node, or node type, is defined in an XML namespace. This is not a
good example to describe the mechanics of JS objects.
................................................................
> 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).
......................................................................
Its not uselss to add new properties to an object at runtime.
It is possible to examine a JS object and determine what properties exist,
and this technique is often used in DOM programming.
......................................................................
> 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.
Actually, in the implementation, you can work with objects (like in
smalltalk where you can change base of an object, and I suspect
prototype.js does the same) but IMHO metaobjects are just an
implementation of classes.
--
Michael
....................................................................
I don't know what this file 'prototype.js' is, AFAIK a JS prototpye object
is built into the languge and is not available as a JS file.
But in JS all objects are built upon the built-in basic Object type, not
classes.
Michael Doubez
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).
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.
In french, we have an epression which would translate as "Making the
donkey to have grain".
> > >> 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.
>
> > > 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.
Answered elsewhere.
> > >> People can argue that a member function is not part of an object
> > >> because
> > >> the
> > >> opcode of the function is not actually stored inside the object. But
> > >> they
> > >> are wrong because an object *does* contain functions.
>
> > > In the conext of C++, functions are member in the same sense as
> > > someone is the member of a club. Being a member of a clud does't me
> > > the club contains you. They are the privileged function that can
> > > access all members and even can use the this keyword in their
> > > definition.
>
> > If you are a member of something you belong to it , or are part of it,
> > associated with it . Whatever term you use it just seems like pernickety
> > pedantic babbling to argue against this general meaning.
>
> 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?
You perceive blue light from the sky and deduce that the sky is blue.
Other people looked at flaty land and deduced eart was flat.
>
> > >> 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.
> > >> :)
>
> > > Repeating something like a psittacidea doesn't make it true.
>
> > Are you suggesting something is untrue? If so what?
>
> Are you suggesting something is true? If so what?
> .....................................................
>
> It was you who made the statement I commented on re:
> "Repeating something like a psittacidea doesn't make it true."
>
> It was unclear what you were suggesting with this statement. Now it's
> apparent you either didn't/don't know what you were talking about or you are
> deliberately trying to introduce confusion.
Your main claim, repeated ad nauseum, without backing, that member
functions are part of objects.
> Well that explains alot.
> FYI the term you used ref "vulgarisation magazine" would generally be
> considered to mean a pornography magazin
:)
In french it is a synonym of simplification/popularisation.
I don't know how you call such magazine in english.
--
Michael
Paul
********************************************
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.
You still haven't said what color the sky is in your world. All you do is
avoid giving any direct answer.
.
****************************************************
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.
**************************************
Well we're not talking French here.
> > >> 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.
>
> > > 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.
Answered elsewhere.
***********************************
You haven't answered it correctly, if so please remind us which colour you
said it was.
You seem unable to answer this simple question.
> > >> People can argue that a member function is not part of an object
> > >> because
> > >> the
> > >> opcode of the function is not actually stored inside the object. But
> > >> they
> > >> are wrong because an object *does* contain functions.
>
> > > In the conext of C++, functions are member in the same sense as
> > > someone is the member of a club. Being a member of a clud does't me
> > > the club contains you. They are the privileged function that can
> > > access all members and even can use the this keyword in their
> > > definition.
>
> > If you are a member of something you belong to it , or are part of it,
> > associated with it . Whatever term you use it just seems like pernickety
> > pedantic babbling to argue against this general meaning.
>
> 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?
You perceive blue light from the sky and deduce that the sky is blue.
Other people looked at flaty land and deduced eart was flat.
**********************************
The sky *is* blue.
You don't know what color it is.
>
> > >> 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.
> > >> :)
>
> > > Repeating something like a psittacidea doesn't make it true.
>
> > Are you suggesting something is untrue? If so what?
>
> Are you suggesting something is true? If so what?
> .....................................................
>
> It was you who made the statement I commented on re:
> "Repeating something like a psittacidea doesn't make it true."
>
> It was unclear what you were suggesting with this statement. Now it's
> apparent you either didn't/don't know what you were talking about or you
> are
> deliberately trying to introduce confusion.
Your main claim, repeated ad nauseum, without backing, that member
functions are part of objects.
*************************************
I do have lots of backing, Bjarne Stroutsrup has written many papars that
describe calling member function on Objects.
There is thousands of papers online that support me.
> Well that explains alot.
> FYI the term you used ref "vulgarisation magazine" would generally be
> considered to mean a pornography magazin
:)
In french it is a synonym of simplification/popularisation.
I don't know how you call such magazine in english.
*********************************
Dunno maybe its one of those french things that cannot be translated
Öö Tiib
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.
> > 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.
> > 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.
Michael Doubez
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.
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
Michael Doubez
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
Paul
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.
>
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'
Paul
--
......................................
No people do agree, its just this newsgroup that do not agree with the
geneal public.
stan
> "Michael Doubez" <michael...@free.fr> 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.....
Michael Doubez
> "Michael Doubez" <michael.dou...@free.fr> wrote in message
>
> 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
Martín 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
gwowen
> 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.
Öö Tiib
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.
Michael Doubez
Ok. I stand corrected.
--
Michael