Re: OOPs!! When is a class not a class? (Re: Number/Specificality/Archetypes in Language)

Forgot to look at the "reply to" address... Jeg sender
videre...
>
>  --- Pablo Flores <pablodavidflores@...>
> skrev:
>
> > If you do "a + b" and you don't know what type of
> > value you put into those variables, that's a
> problem
> > with your program, not with the operator. :)
> >
> > I agree that a good programming language should
> > not be as paternalistic as to assume that, when
> you
> > wrote '2' + '2', you actually meant 2 + 2...
> >
> I didn't fancy the problem. See what Our Beloved
> David
> Flanagan says in  the Holy Book, chapter 11, section
> "Converting objects into primary values" (my
> regrettable re-translation):
>
> "However, there are some [places ?] in JavaScript
> where the context is ambiguous ! [please note the
> exclamation mark] The operator + and the comparison
> operators (<, <=, > and >=) operate both on numbers
> and strings, so that, when an object is used with
> one
> of those operators, it is difficult [please not the
> adjective: difficult] to say whether it should be
> converted into a number or a string. In most cases,
> JavaScript first tries [please note: most cases, and
> tries] to convert the object by calling its method
> valueOf(). If this method returns a value (usually
> [please note: usually] a number], this value is
> used.
> However, in most of cases valueOf() simply returns
> the
> object without conversion [interesting !]; in that
> case, JavaScript then tries [tries] to convert the
> object into a string by calling its method
> toString().
>
> (Skipping next paragraph: if the object is a date,
> it
> still works another way)
>
> Most of objects have no valueOf() returning useful
> results. When you use an object with the operator +,
> you usually get a string concatenation rather than
> an
> addition (snip)
>
> If you defined a valueOf() method returning a
> number,
> you can use arithmetic operators, or others, on that
> object, but adding your object to a string might
> bring
> an unexpected behaviour: the toString() method is
> not
> called any more, and a string representation of the
> number returned by valueOf() is concatenated to the
> string" [aaaargh]
>
> So, is it a string ? is it a number ? is it a bird
> or
> is it a plane ? Seems hard to say. And if David
> Flanagan, Lord of JavaScript and Graduated of the
> MIT,
> uses such words as "difficult", "ambiguous",
> "usually", "try" and "unexpected", so who am I,
> miserable worm, to contest His Words ? Nothing at
> all.
>
> (Of course, I would not try to write something like
> 'x
> = "aaa" + "bbb"' in a Pick Basic program. I just
> explained how Pick Basic would handle it. Usually,
> it
> would rather be 'x = a + b', where a and b might
> happen to be strings, for ex if you confused the
> decimal point with the (French) decimal comma. If a
> contains 2,35 and b contains 1,10 this is correct in
> French but not in Basic, except if you redefined,
> etc,
> etc...)
> -----
> Said John Cowan:
>
> "It's a matter of point of view.  If you conceive of
> concatenation
> as "string addition" (in the same way that we
> conceive
> of integer
> and floating-point addition as being "the same
> thing",
> though to the
> CPU they are utterly different), then it makes sense
> to use the same
> operator for them.  But if you conceive of
> concatenation and addition
> as two different things, it makes sense to use two
> different operators."
>
> I agree. To me, these are completely different
> concepts and there is no reason to use the same
> symbol
> for both, except maybe that there wasn't any common
> symbol at hand any more, which would be a very bad
> reason indeed.
>
> "I've always liked Ada's solution for & and | vs. &&
> and
> ||.
> Ada uses keywords rather than symbols in most
> situations, and so writes
> "and" and "or" for the simple operators; the
> relationship of the
> shortcut
> operators to conditionals is explicitly recognized
> by
> writing "and
> then"
> and "or else", and this makes a handy way to read &&
> and || out loud in
> C-derived languages."
>
> I don't know Ada, but this looks nice. My idea was
> to
> represent all operator concepts by 3-char mnemonics,
> like "ADD" for Addition, "CCT" for concatenating,
> etc... well, looks rather much like Assembler,
> doesn't
> it ? So you could write programs using these codes,
> and then a processor would translate it into Cobol,
> Pascal, JavaScript or whatever. (Probably too
> simple,
> there must be some problem somewhere).
>
> --------
> Said Keith Gaughan:
>
> Keith Gaughan:
>
> "Don't know much about Pick BASIC, but it's probably
> completely untyped."
>
> It is.
>
> "JavaScript objects are all typed, and variables
> gain
> a type when you do
> an assignment. That way, it doesn't get mixed up
> when
> you're doing
> concatenation or addition."
>
> (See above)
>
> "I don't know if you've heard of it, but the
> language
> Tcl similarly to
> how you've described Pick BASIC, treating everything
> as a string."
>
> Well, TCL is used on Pick Systems. It's more or less
> at the same level as SQL on other systems. There is
> also something very unfriendly called "PROC",
> allowing
> you to write scripts. PROC is the worst part of Pick
> Systems. But I cannot see that Pick Basic "treats
> everything like a string" - or maybe you mean that
> it
> parses the value before trying to do some arithmetic
> operation on it ?
>
> "The use of ":" for concatenation is very unusual!"
>
> I think it was more common earlier. ":" is also used
> (by Pick) in the PRINT instruction:
>
> PRINT "BONJOUR":
> will print the word without a linefeed after it,
> while:
> PRINT "BONJOUR"
> will send a linefeed after the string. And it is not
> so stupid, because there seem to be more cases where
> you would be happy to get the linefeed without
> having
> to add "\n" or other esoteric codes than the
> contrary.
>
> ( ";" is used to separate instructions on a same
> line,
> but no Pick instruction has to be ended by ";", or
> ".", or whatever)
>
> --------
> (To John Cowan):
> "Apache" means "malfaiteur, bandit" in French (and
> also "Apache", of course), but this sounds a little
> outdated by now. Anyway, I guess it's not
> politically
> correct at all.
>
>
> =====
> Philippe Caquant
>
>
> Ceterum censeo *vi* esse oblitterandum (Me).
>
=====
Philippe Caquant


Ceterum censeo *vi* esse oblitterandum (Me).

Reply