public fields in API classes

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

public fields in API classes

Attila Szegedi
I just noticed something.

freemarker.core.ast.Expression subclasses are immutable -- their fields  
are all final. There's a problem with them however. I noticed that in 2.3  
-> 2.4 transition, their fields were changed (by Jonathan, I assume) from  
"private final" to "public final". I don't really like the approach. I  
mean, do we want to have *fields* in the supported public API of our  
classes? Providing getter methods is the usually accepted practice that  
allows you the freedom to change the internal representation flexibly if  
needed. Joshua Bloch (a guy who wrote quite a lot of the core Java  
libraries) has a book "Effective Java"  
<http://java.sun.com/docs/books/effective/> where he specificially  
discourages the practice in chapter 4 "Classes and Interfaces", item 13  
"Favor immutability".

And then there's one more reason. Namely, you can change the value of  
final fields through JNI. Just take a look at some of the top hits from  
<http://www.google.com/search?rls=en&q=modify+final+field+JNI>.

This is not a bug, it is rather an "undocumented feature" that various Sun  
sources declared on multiple occasions is there to stay, since it makes  
native code of certain core java.* classes work - most notably  
deserialization. If you remember, serialization framework can deserialize  
your objects that have final fields, and it doesn't invoke any  
constructors in the process. How does it do it then? Well, by directly  
writing final fields using JNI, of course. Deserialization code can write  
even to private final fields - since it is running in the system  
privileged security domain, but any JNI code can write public final  
fields, since they're public and JNI doesn't observe finality. Thus, any  
JNI code would be able to modify our Expression objects. I'd say let's  
revert them back to being private...

Attila.

--
home: http://www.szegedi.org
weblog: http://constc.blogspot.com

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
FreeMarker-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freemarker-devel
Reply | Threaded
Open this post in threaded view
|

Re: public fields in API classes

Daniel Dekany
Saturday, September 16, 2006, 11:36:35 AM, Attila Szegedi wrote:

> I just noticed something.
>
> freemarker.core.ast.Expression subclasses are immutable -- their fields
> are all final. There's a problem with them however. I noticed that in 2.3
->> 2.4 transition, their fields were changed (by Jonathan, I assume) from  
> "private final" to "public final". I don't really like the approach.
> I mean, do we want to have *fields* in the supported public API of
> our classes? Providing getter methods is the usually accepted
> practice that allows you the freedom to change the internal
> representation flexibly if needed.

I agree that those fields should be private with public getters.

> Joshua Bloch (a guy who wrote quite a lot of the core Java
> libraries) has a book "Effective Java"
> <http://java.sun.com/docs/books/effective/> where he specificially
> discourages the practice in chapter 4 "Classes and Interfaces", item
> 13 "Favor immutability".

It seems Sun, or whoever is responsible for the Java Language, is
either not aware of the above mentioned convention or simply doesn't
give a shit. You see, most field+getter+setter stuff looks the same,
so it is not exciting to fill a high percentage of program lines with
them at all. Do the Java Language give any shortcut for defining these
trios? Like "public property int x;"? No. I find this very tiresome
and completely lame even if Eclipse code generator features help
somewhat. I guess that was the reason of Jonathan doing this. I have
actually considered this for internal API-s as well. But, this is
public API, so...

> And then there's one more reason. Namely, you can change the value of
> final fields through JNI. Just take a look at some of the top hits from
> <http://www.google.com/search?rls=en&q=modify+final+field+JNI>.
>
> This is not a bug, it is rather an "undocumented feature" that
> various Sun sources declared on multiple occasions is there to stay,
> since it makes native code of certain core java.* classes work -
> most notably deserialization. If you remember, serialization
> framework can deserialize your objects that have final fields, and
> it doesn't invoke any constructors in the process. How does it do it
> then? Well, by directly writing final fields using JNI, of course.
> Deserialization code can write even to private final fields - since
> it is running in the system privileged security domain, but any JNI
> code can write public final fields, since they're public and JNI
> doesn't observe finality. Thus, any JNI code would be able to modify
> our Expression objects. I'd say let's revert them back to being
> private...
>
> Attila.

--
Best regards,
 Daniel Dekany


-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
FreeMarker-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freemarker-devel
Reply | Threaded
Open this post in threaded view
|

Re: public fields in API classes

Attila Szegedi
On Sun, 17 Sep 2006 18:42:39 +0200, Daniel Dekany <[hidden email]>  
wrote:

>
> It seems Sun, or whoever is responsible for the Java Language, is
> either not aware of the above mentioned convention or simply doesn't
> give a shit. You see, most field+getter+setter stuff looks the same,
> so it is not exciting to fill a high percentage of program lines with
> them at all. Do the Java Language give any shortcut for defining these
> trios? Like "public property int x;"? No. I find this very tiresome
> and completely lame even if Eclipse code generator features help
> somewhat.

I agree completely. C# does it a little bit more economically, i.e. you  
can write

private int x;
...
public int X
{
     get
     {
         return x;
     }
     set
     {
         x = value;
     }
}
("value" is a fixed name for setter's values).

But Ruby is definitely the king in this regard. Since in Ruby, classes can  
modify their definition, there are two built-in function on classes  
that'll define trivial getters and setters for the symbols:

class Person
     attr_reader :firstName, :lastName, :address
     attr_writer :address
end

"attr_reader :address" will generate a method

def address
     @address
end

in the class, and "attr_writer: address" will generate a method

def address=(newAddress)
     @address = newAddress
end

Of course, if you ever need to customize them, you just remove the  
attr_reader or attr_writer declaration and implement the methods yourself,  
without a change to the public API of the class. Very nice. Too bad I  
don't work in Ruby :-)

Attila...

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
FreeMarker-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freemarker-devel
Reply | Threaded
Open this post in threaded view
|

Re: public fields in API classes

Daniel Dekany
Monday, September 18, 2006, 9:29:42 AM, Attila Szegedi wrote:

> On Sun, 17 Sep 2006 18:42:39 +0200, Daniel Dekany <[hidden email]>
> wrote:
>
>>
>> It seems Sun, or whoever is responsible for the Java Language, is
>> either not aware of the above mentioned convention or simply doesn't
>> give a shit. You see, most field+getter+setter stuff looks the same,
>> so it is not exciting to fill a high percentage of program lines with
>> them at all. Do the Java Language give any shortcut for defining these
>> trios? Like "public property int x;"? No. I find this very tiresome
>> and completely lame even if Eclipse code generator features help
>> somewhat.
>
> I agree completely. C# does it a little bit more economically, i.e. you
> can write
>
> private int x;
> ...
> public int X
> {
>      get
>      {
>          return x;
>      }
>      set
>      {
>          x = value;
>      }
> }
> ("value" is a fixed name for setter's values).

Better than Sun's solution, of course... (and maybe then I can just
write foo.X = 123;?) However it is still too long for the purpose. I
don't see anything interesting above, yet it was several lines and
bocks.

> But Ruby is definitely the king in this regard. Since in Ruby, classes can
> modify their definition, there are two built-in function on classes  
> that'll define trivial getters and setters for the symbols:
>
> class Person
>      attr_reader :firstName, :lastName, :address
>      attr_writer :address
> end

Now this *much* better (even if not 100% optimal for the purpose, but
I can swallow this as a sacrifice on the altar of generalization).

> "attr_reader :address" will generate a method
>
> def address
>      @address
> end
>
> in the class, and "attr_writer: address" will generate a method
>
> def address=(newAddress)
>      @address = newAddress
> end
>
> Of course, if you ever need to customize them, you just remove the  
> attr_reader or attr_writer declaration and implement the methods yourself,
> without a change to the public API of the class. Very nice. Too bad I
> don't work in Ruby :-)

And I'm still looking for a more-less platform independent compiled
language (I count Java Language as compiled) that is developed with
creative people like Ruby and Python people are... The point is not
the speed, but the reliability. Now really, do compiled languages tend
to attract ass-holes somehow (Like me? :) ), or what is this???

--
Best regards,
 Daniel Dekany


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
FreeMarker-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freemarker-devel
Reply | Threaded
Open this post in threaded view
|

OT: alternative languages, was Re: public fields in API classes

Attila Szegedi
On Mon, 18 Sep 2006 22:24:04 +0200, Daniel Dekany <[hidden email]>  
wrote:

>
> And I'm still looking for a more-less platform independent compiled
> language (I count Java Language as compiled) that is developed with
> creative people like Ruby and Python people are... The point is not
> the speed, but the reliability.

I think the term you're looking for is not "compiled", but rather  
"statically typed".

> Now really, do compiled languages tend
> to attract ass-holes somehow (Like me? :) ), or what is this???

Try Scala. To me, in lots of regards, it is what Java should have been. It  
is a dual functional/object-oriented language, compiles to either JVM or  
CLR bytecode (so it's 100% interoperable with either Java or C#). It is  
statically typed, but the compiler is type-inferring, i.e. it can guess  
the types from the context in most cases when they're not declared  
explicitly (var s = "foo" -- s is trivially a String). It's great talking  
to a somewhat intelligent compiler finally :-)

Go to <http://scala.epfl.ch/docu/> and read "Scala by Example"  
(preferrably the PDF version) if you're interested.

Attila.

--
home: http://www.szegedi.org
weblog: http://constc.blogspot.com

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
FreeMarker-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freemarker-devel
Reply | Threaded
Open this post in threaded view
|

Re: OT: alternative languages, was Re: public fields in API classes

Daniel Dekany
Tuesday, September 19, 2006, 5:58:33 AM, Attila Szegedi wrote:


> On Mon, 18 Sep 2006 22:24:04 +0200, Daniel Dekany <[hidden email]>
> wrote:
>
>>
>> And I'm still looking for a more-less platform independent compiled
>> language (I count Java Language as compiled) that is developed with
>> creative people like Ruby and Python people are... The point is not
>> the speed, but the reliability.
>
> I think the term you're looking for is not "compiled", but rather  
> "statically typed".

Yes, basically at least...

>> Now really, do compiled languages tend
>> to attract ass-holes somehow (Like me? :) ), or what is this???
>
> Try Scala. To me, in lots of regards, it is what Java should have been. It
> is a dual functional/object-oriented language, compiles to either JVM or
> CLR bytecode (so it's 100% interoperable with either Java or C#). It is
> statically typed, but the compiler is type-inferring, i.e. it can guess
> the types from the context in most cases when they're not declared  
> explicitly (var s = "foo" -- s is trivially a String). It's great talking
> to a somewhat intelligent compiler finally :-)
>
> Go to <http://scala.epfl.ch/docu/> and read "Scala by Example"  
> (preferrably the PDF version) if you're interested.

Hm, I will look into it. Looks promising at the first glance. However,
it caught my eye that while == is something like Object.equals in
Java, it allows comparisons to null, and the result will be
true/false. I sounds totally insane...

--
Best regards,
 Daniel Dekany


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
FreeMarker-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freemarker-devel
Reply | Threaded
Open this post in threaded view
|

Re: OT: alternative languages, was Re: public fields in API classes

Daniel Dekany
Wednesday, September 20, 2006, 1:22:28 PM, Daniel Dekany wrote:


> Tuesday, September 19, 2006, 5:58:33 AM, Attila Szegedi wrote:
>
>
>> On Mon, 18 Sep 2006 22:24:04 +0200, Daniel Dekany <[hidden email]>
>> wrote:
>>
>>>
>>> And I'm still looking for a more-less platform independent compiled
>>> language (I count Java Language as compiled) that is developed with
>>> creative people like Ruby and Python people are... The point is not
>>> the speed, but the reliability.
>>
>> I think the term you're looking for is not "compiled", but rather  
>> "statically typed".
>
> Yes, basically at least...
>
>>> Now really, do compiled languages tend
>>> to attract ass-holes somehow (Like me? :) ), or what is this???
>>
>> Try Scala. To me, in lots of regards, it is what Java should have been. It
>> is a dual functional/object-oriented language, compiles to either JVM or
>> CLR bytecode (so it's 100% interoperable with either Java or C#). It is
>> statically typed, but the compiler is type-inferring, i.e. it can guess
>> the types from the context in most cases when they're not declared  
>> explicitly (var s = "foo" -- s is trivially a String). It's great talking
>> to a somewhat intelligent compiler finally :-)
>>
>> Go to <http://scala.epfl.ch/docu/> and read "Scala by Example"  
>> (preferrably the PDF version) if you're interested.
>
> Hm, I will look into it. Looks promising at the first glance. However,
> it caught my eye that while == is something like Object.equals in
> Java, it allows comparisons to null, and the result will be
> true/false. I sounds totally insane...

IT sounds... etc.

--
Best regards,
 Daniel Dekany


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
FreeMarker-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freemarker-devel
Reply | Threaded
Open this post in threaded view
|

Re: OT: alternative languages, was Re: public fields in API classes

Attila Szegedi
On Wed, 20 Sep 2006 13:34:53 +0200, Daniel Dekany <[hidden email]>  
wrote:

>
>> Hm, I will look into it. Looks promising at the first glance. However,
>> it caught my eye that while == is something like Object.equals in
>> Java, it allows comparisons to null, and the result will be
>> true/false. I sounds totally insane...


Well, since a == b translates to a.equals(b), iAmNotNull == null returns  
false, which is natural. For reasons of symmetry, null == iAmNotNull  
returns false too. With all this in place, why not support null == null  
too? Doesn't look like too much of a heresy to me.

Attila.

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
FreeMarker-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freemarker-devel
Reply | Threaded
Open this post in threaded view
|

Re: OT: alternative languages, was Re: public fields in API classes

Daniel Dekany
Wednesday, September 20, 2006, 3:47:50 PM, Attila Szegedi wrote:


> On Wed, 20 Sep 2006 13:34:53 +0200, Daniel Dekany <[hidden email]>
> wrote:
>
>>
>>> Hm, I will look into it. Looks promising at the first glance. However,
>>> it caught my eye that while == is something like Object.equals in
>>> Java, it allows comparisons to null, and the result will be
>>> true/false. I sounds totally insane...
>
> Well, since a == b translates to a.equals(b), iAmNotNull == null returns
> false, which is natural.

Um... I don't get it. It can hardly be called natural, if it's plain
wrong, assuming we respect nature at least. And null means "points to
no object", even if some languages use a singleton object as null. So
how on the earth would anything compare something with another object
that is not pointed at all, i.e. is not known? You see, you can
compare the first name of two concrete persons, but for example you
can not compare the first name of a concrete person with the lack of a
person. They are not even on common units of measurement... a name,
and a fact that tells something is missing.

Now, when somebody handles null comparisons like this in its one-man
hobby project, I just step over it, because I know it is an easy
mistake (overlooking) to do for somebody who writes programs in
C/Pascal/Java Language (where ==, basically, does pointer comparison).
But I find it very confusing when it comes from people who are
computer language experts, or even computer language researchers. I
must misunderstand something. And in programming theory and practice
is often the same thing.... in this case, if the language gives wrong
answers in the case of certain comparisons, that's not good for the
reliability and mailability of the programs written on that language.

> For reasons of symmetry, null == iAmNotNull
> returns false too. With all this in place, why not support null == null
> too? Doesn't look like too much of a heresy to me.

Saying things like "2 plus 2 is 3" is heresy in programming...

--
Best regards,
 Daniel Dekany


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
FreeMarker-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freemarker-devel
Reply | Threaded
Open this post in threaded view
|

Re: public fields in API classes

revusky
In reply to this post by Attila Szegedi
Attila Szegedi wrote:
> I just noticed something.
>
> freemarker.core.ast.Expression subclasses are immutable -- their fields  
> are all final. There's a problem with them however. I noticed that in 2.3  
> -> 2.4 transition, their fields were changed (by Jonathan, I assume) from  
> "private final" to "public final".

The reason is that I broke freemarker.core into several different
subpackages and frequently stuff in one package needs to get at stuff in
another. That's basically it.

In many case, I think, the field was just package visible and I ended
making it public.

> I don't really like the approach. I  
> mean, do we want to have *fields* in the supported public API of our  
> classes? Providing getter methods is the usually accepted practice that  
> allows you the freedom to change the internal representation flexibly if  
> needed. Joshua Bloch (a guy who wrote quite a lot of the core Java  
> libraries) has a book "Effective Java"  
> <http://java.sun.com/docs/books/effective/> where he specificially  
> discourages the practice in chapter 4 "Classes and Interfaces", item 13  
> "Favor immutability".
>
> And then there's one more reason. Namely, you can change the value of  
> final fields through JNI. Just take a look at some of the top hits from  
> <http://www.google.com/search?rls=en&q=modify+final+field+JNI>.

Well, that something that is supposed to be immutable could be changed
via JNI is not something I would worry about much.

Anyway, all of that stuff is in a very transitional state right now. I
haven't been doing much with any of it for a couple of months now and I
don't know when I'll get back into it. It's good to see that you're
jumping into the code again.

>
> This is not a bug, it is rather an "undocumented feature" that various Sun  
> sources declared on multiple occasions is there to stay, since it makes  
> native code of certain core java.* classes work - most notably  
> deserialization. If you remember, serialization framework can deserialize  
> your objects that have final fields, and it doesn't invoke any  
> constructors in the process. How does it do it then? Well, by directly  
> writing final fields using JNI, of course. Deserialization code can write  
> even to private final fields - since it is running in the system  
> privileged security domain, but any JNI code can write public final  
> fields, since they're public and JNI doesn't observe finality. Thus, any  
> JNI code would be able to modify our Expression objects. I'd say let's  
> revert them back to being private...

Well, I don't want to give the impression that I care about this too
much, but if the main reason was this JNI business, I don't see it. That
just strikes me as an ersatz problem frankly....

JR

>
> Attila.
>



-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
FreeMarker-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freemarker-devel
Reply | Threaded
Open this post in threaded view
|

Re: OT: alternative languages, was Re: public fields in API classes

Attila Szegedi
In reply to this post by Daniel Dekany
On Wed, 20 Sep 2006 16:33:39 +0200, Daniel Dekany <[hidden email]>  
wrote:

>
> Um... I don't get it. It can hardly be called natural, if it's plain
> wrong, assuming we respect nature at least. And null means "points to
> no object", even if some languages use a singleton object as null. So
> how on the earth would anything compare something with another object
> that is not pointed at all, i.e. is not known? You see, you can
> compare the first name of two concrete persons, but for example you
> can not compare the first name of a concrete person with the lack of a
> person. They are not even on common units of measurement... a name,
> and a fact that tells something is missing.

Except this is not comparison as in "ordering", but a weaker concept -  
equality check. Scala thinks its acceptable to say that any concrete name  
doesn't equal the lack of the name, hence their equality test returns  
false. I mean, even in Java "new Object().equals(null)" will evaluate to  
false, and won't throw an exception. And in Scala, "obj == null"  
translates to "obj.equals(null)" under the hood. Of course, you can  
question if you wish whether the practice of Java encouraging  
implementations of equals to return false on null argument is correct. In  
contrast, Comparable and Comparator implementations are encouraged to  
throw NPE on comparator.compare(obj, null) and comparable.compareTo(null),  
although not obliged - they can choose to sort null higher or lower than  
all other values. I think the only really interesting question is what  
should the correct value of "null == null" be in Scala. It happens to be  
true, but one could of course bring up quite valid arguments for "false"  
as well, or escape to the realm of three-state logic (true, false,  
unknown) like SQL does.

Attila.

--
home: http://www.szegedi.org
weblog: http://constc.blogspot.com

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
FreeMarker-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freemarker-devel
Reply | Threaded
Open this post in threaded view
|

Re: OT: alternative languages, was Re: public fields in API classes

Daniel Dekany
Thursday, September 21, 2006, 10:56:54 AM, Attila Szegedi wrote:


> On Wed, 20 Sep 2006 16:33:39 +0200, Daniel Dekany <[hidden email]>
> wrote:
>
>>
>> Um... I don't get it. It can hardly be called natural, if it's plain
>> wrong, assuming we respect nature at least. And null means "points to
>> no object", even if some languages use a singleton object as null. So
>> how on the earth would anything compare something with another object
>> that is not pointed at all, i.e. is not known? You see, you can
>> compare the first name of two concrete persons, but for example you
>> can not compare the first name of a concrete person with the lack of a
>> person. They are not even on common units of measurement... a name,
>> and a fact that tells something is missing.
>
> Except this is not comparison as in "ordering", but a weaker concept -
> equality check. Scala thinks its acceptable to say that any concrete name
> doesn't equal the lack of the name, hence their equality test returns
> false. I mean, even in Java "new Object().equals(null)" will evaluate to
> false, and won't throw an exception. And in Scala, "obj == null"  
> translates to "obj.equals(null)" under the hood. Of course, you can  
> question if you wish whether the practice of Java encouraging  
> implementations of equals to return false on null argument is correct.

Now maybe the problem was exactly that these people was *computer
language* experts... When people write valve1State == valve2Sate, they
mean to test if the two valves are in the same state. They really
don't give a shit if what kind of brain attack did academic people
done that would justify that the program has assumed that both valves
are in the same state when in fact their state was no known yet
(null).

> In
> contrast, Comparable and Comparator implementations are encouraged to
> throw NPE on comparator.compare(obj, null) and comparable.compareTo(null),
> although not obliged - they can choose to sort null higher or lower than
> all other values. I think the only really interesting question is what
> should the correct value of "null == null" be in Scala.

Error in all languages. If they think they an Object.equal-like
operator needed with this strange behavior with null-s, use some
exotic symbol... ~== or whatever.

> It happens to be true, but one could of course bring up quite valid
> arguments for "false" as well, or escape to the realm of three-state
> logic (true, false, unknown) like SQL does.

Actually the SQL solution (x == null evaluates to null) is not that
bad either... or at least it is not clearly wrong, just maybe not too
practical.

> Attila.

--
Best regards,
 Daniel Dekany


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
FreeMarker-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freemarker-devel