A suggestion

[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).
********************************************
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.

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

 

[Paul]

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

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,.

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'

 

[Michael Doubez]

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.


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++).

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.

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.

 

[Paul]

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.


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++).

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.

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.

 

[stan]

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++.



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

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?

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

Perhaps you could explain the purpose of the standard?

Morons patiently standing by awaiting enlightenment.....

 

[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++).







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.







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
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.

 

[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]

"Michael Doubez" <[email protected]> wrote in message

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++).

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.

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
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.

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]

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.

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.