[RFE] Access to Field, Method and Constructor without the use of Strings

java-programmer, [RFE] Access to Field, Method and Constructor without the use of Strings
Hi all,

I submitted the following RFE to Sun's RFE page.

As a reply I received a mail from Girish Manwani at Sun that I
should start a discussion in one of the Java newsgroups (Huh?).
To my knowledge, this is the most appropriate group. Here gos:

A DESCRIPTION OF THE REQUEST:
It should be possible to obtain references to Field, Method and
Constructor objects without the use of strings. Proposed syntax:

// Assuming the following class
public class Foo {

String bar;

public Foo(String bar) {
this.bar = bar;
}

public void fly(String to) {
bar = to;
}
}

Field fooBarField = Foo.class.bar.field;
Method fooFlyMethod = Foo.class.fly.method(new Object[]{String.class});
Constructor fooConstructor = Foo.class.constructor(new Object[]{String.class});

There are other possible options for the syntax. I would just like to see
this principally possible.

The construct is similar to the ClassName.class syntax and it can be treated
by the Compiler in the same way:
It could produce the getDeclaredField, getDeclaredMethod and getConstructor
bytecode. No modifications to the JVM would be necessary.

JUSTIFICATION :
The existance of the field/method/constructor could be checked during compile
time. Typos would no longer be possible.

A notation without strings could be very easily refactored by IDEs.

We would specifically need the feature for our typesafe querying system,
so it could work completely without strings.
http://sodaquery.sf.net/

The possibility to get Method objects without strings, would encourage many
developers to use them for more dynamic programming and would result in lots
of more flexible libraries for the Java platform.

Thanks in advance for your attention and for positive comments.

Kind regards,
Carl
Carl Rosenberger
db4o - database for objects - http://www.db4o.com

java-programmer >> [RFE] Access to Field, Method and Constructor without the use of Strings "Carl Rosenberger" <email***@***.com> wrote in message news:<bkc2ml$qdt$01$email***@***.com>...
> Hi all,
>
> I submitted the following RFE to Sun's RFE page.
>
> As a reply I received a mail from Girish Manwani at Sun that I
> should start a discussion in one of the Java newsgroups (Huh?).

Interesting. I wonder if that means Sun actually monitors
Java newsgroups, or if that is their polite way to
say "go away, we are too busy"!

FWIW, Sounds like a small and useful addition.
(Then there was the variable-shadowing issue discussed
elsewhere, though I don't know if that can
be fixed without breaking existing code.)

java-programmer >> [RFE] Access to Field, Method and Constructor without the use of Strings "Carl Rosenberger" <email***@***.com> wrote in message news:<bkc2ml$qdt$01$email***@***.com>...
> Hi all,
>
> I submitted the following RFE to Sun's RFE page.
>
> ...
>
> A DESCRIPTION OF THE REQUEST:
> It should be possible to obtain references to Field, Method and
> Constructor objects without the use of strings. Proposed syntax:
>
> ...
>
> JUSTIFICATION :
> The existance of the field/method/constructor could be checked during compile
> time. Typos would no longer be possible.
>
> A notation without strings could be very easily refactored by IDEs.
>
> ...

But the usual reason for using reflection is that those
classes/fields/methods/constructors don't exist at compile time
and may or may not exist at run time.

-Larry Barowski

java-programmer >> [RFE] Access to Field, Method and Constructor without the use of Strings In article <bkc2ml$qdt$01$email***@***.com>,
Carl Rosenberger <email***@***.com> wrote:
>
>Hi all,
>
>I submitted the following RFE to Sun's RFE page.

I'm behind you all the way :-)

I have two main reasons for wanting this. First, it would make me feel
a lot easier about the legacy library we have that makes heavy use of
field reflection. Right now, detection of typos is effectively left to
run-time and I really really hate that. Second, it would become
feasible to make heavier use of reflection without feeling that you're
programming Perl or something.

Is it possible to vote for this RFE on Sun's site?

Cheers
Bent D
--
Bent Dalager - email***@***.com - http://www.pvv.org/~bcd
powered by emacs

java-programmer >> [RFE] Access to Field, Method and Constructor without the use of Strings On Thu, 18 Sep 2003 12:53:09 +0200, Carl Rosenberger wrote:
> The existance of the field/method/constructor could be checked
> during compile time. Typos would no longer be possible.

It could only be checked at compile time if the compiler has access to
the class in question.

And if that's the case, you can use "regular" syntax to access the
fields and get the checking you're asking for, without using
reflection at all.

/gordon

--
[ do not email me copies of your followups ]
g o r d o n + n e w s @ b a l d e r 1 3 . s e

java-programmer >> [RFE] Access to Field, Method and Constructor without the use of Strings Bent C Dalager wrote:
> >I submitted the following RFE to Sun's RFE page.
>
> I'm behind you all the way :-)

Thanks for the backup.

> Is it possible to vote for this RFE on Sun's site?

I don't think so. Attached I send along the answer from Sun.

It tells me to discuss the theme in a newsgroup and to
submit the RFE again, if there is positive feedback.

Funny:
I submitted a similar RFE for access to methods only, more
than three years ago. At that time my suggestion as to the
syntax wasn't too good but the idea was the same. I can attach
the answer I received at that time to this mail also.

How many times do they want me to submit this RFE until it
gos into the database?

Cheers,
Carl

******************************* Answer 2 *** 2003 **************************

> -----Original Message-----
> From: Girish Manwani [mailto:email***@***.com]
> Sent: Donnerstag, 14. August 2003 22:03
> To: email***@***.com
> Cc: email***@***.com
> Subject: Re: (Incident Review ID: 185015) Access
> java.lang.reflect.Field, Method and Constructor objects without strings
>
>
>
> Hi Carl Rosenberger,
>
> Thank you for using our bug submit page. There may be merit to
> your request for feature enhancement (RFE). I would suggest
> that you first post this to a newsgroup and request comment from
> other java developers.
>
> You can view a list of Java newsgroups at:
>
> http://java.sun.com/aboutJava/newsgroups.html
>
>
> Based on the responses, please feel free to submit a new RFE
> containing a link to the newsgroup. Thank you for your time.
>
> Regards,
> Girish
> ----------------- Original Bug Report-------------------
>
> category : java
> release : 1.4.1
> subcategory : classes_lang
> type : rfe
> synopsis : Access java.lang.reflect.Field, Method and Constructor
> objects without strings
> description : A DESCRIPTION OF THE REQUEST :
> It should be possible to obtain references to Field, Method and
> Constructor objects without the use of strings. Proposed syntax:
>
> // Assuming the following class
> public class Foo {
> String bar;
> public Foo(String bar) {
> this.bar = bar;
> }
> public void fly(String to) {
> bar = to;
> }
> }
>
> Field fooBarField = Foo.class.bar.field;
> Method fooFlyMethod = Foo.class.fly.method(new Object[]{String.class});
> Constructor fooConstructor = Foo.class.constructor(new
> Object[]{String.class});
>
> There are other possible options for the syntax. I would just
> like to see this principally possible.
>
> The construct is similar to the ClassName.class syntax and it can
> be treated by the Compiler in the same way:
> It could produce the getDeclaredField, getDeclaredMethod and
> getConstructor bytecode. No modifications to the JVM would be necessary.
>
> JUSTIFICATION :
> The existance of the field/method/constructor could be checked
> during compile time. Typos would no longer be possible.
>
> A notation without strings could be very easily refactored by IDEs.
>
> We would specifically need the feature for our typesafe querying
> system, so it could work completely without strings.
> http://sodaquery.sf.net/
>
> The possibility to get Method objects without strings, would
> encourage many developers to use them for more dynamic
> programming and would result in lots of more flexible libraries
> for the Java platform.
> workaround :
> suggested_val :
> cust_name : Carl Rosenberger
> cust_email : email***@***.com
> jdcid : CarlRosenberger
> keyword : webbug
> company : db4o
> hardware : x86
> OSversion : win_nt_4.0
> bugtraqID : 0
> dateCreated : 2003-04-29 06:29:20.9
> dateEvaluated : 2003-08-14 14:03:03.296
>

******************************* Answer 1 *** 2000 **************************

> -----Original Message-----
> From: Sean Lane [mailto:email***@***.com]
> Sent: Montag, 10. Juli 2000 19:52
> To: email***@***.com
> Subject: Re: (Review ID: 104615) Access to Method object without String
> detour through getMethod
>
>
> I apologize for the length of time it has taken for someone to
> respond to you regarding this Bug Report you have made.
> I hope you will not be offended by us contacting you after
> such a long time. We are very concerned about every Bug
> Report that we receive and with the volume we receive
> we have not able to address all of them is the timely manner
> that we would like. We are looking through our older Bug
> Reports and are trying to find out if these issues are still
> relevant to our customers and want to know if the problem
> still exists in our more recent release.
>
> Please let me know if this problem still exists for you.
>
> Sean Lane
>
> P.S.--
> The following is the most recent release and
> its download site:
>
> JDK 1.3 - http://java.sun.com/j2se/1.3/
>
>
> ----------------- Original Bug Report-------------------
>
> category : java
> subcategory : classes_lang
> type : rfe
> synopsis : Access to Method object without String detour through getMethod
> description : java version "1.2.2"
> Classic VM (build JDK-1.2.2-004, native threads, symcjit)
>
> I would like to be able to store methods into Method variables without the
> detour through Class.getMethod(String, Class[]).
>
> String names for methods within sourcecode
> - are not very performant
> - can not be checked by the compiler
>
> Something like the following would be great:
>
> import java.lang.reflect.*;
> public class MyClass
> {
> public void myMethod(){
> Method foo = new Method(MyClass.myMethod);
> // Alternatives:
> Method foo = new Method(MyClass.myMethod());
> Method foo = new Method(MyClass.class.myMethod);
> Method foo = new Method(MyClass.class.myMethod());
> Method foo = this.getClass().getMethod(MyClass.myMethod);
> Method foo = this.getClass().getMethod(MyClass.myMethod());
> // Maybe sun can think of the syntactic right Java way for this.
> }
> }
> workaround : I use an object to cache the Method so I only need a
> single call to getMethod.
> I still find the String representation of method names spread
> throughout my
> code very irritating.
>
> A portion of my code:
>
> package de.cros.collection;
>
> import java.lang.reflect.*;
>
> public class MethodProperty extends CollectionObjectProperty
> {
> private String i_methodName;
> private Method i_Method;
>
> public MethodProperty(Collection a_Collection, String a_methodName){
> super(a_Collection);
> i_methodName = a_methodName;
> try{
> i_Method =
> a_Collection.getCollectedClass().getMethod
> (a_methodName,null);
> }
> catch(Exception l_ex){
> i_Method = null;
> }
> }
>
> Object get(Object a_Object) throws IllegalAccessException,
> NoSuchMethodException, InvocationTargetException{
> return method(a_Object).invoke(a_Object, null);
> }
>
> private Method method(Object a_Object) throws NoSuchMethodException{
> if (i_Method != null){
> return i_Method;
> }
> return a_Object.getClass().getMethod(i_methodName, null);
> }
> }
> suggested_val :
> cust_name : Carl Rosenberger
> cust_email : email***@***.com
> jdcid : CarlRosenberger
> keyword : webbug
> company : c-ros www.c-ros.de
> release : 1.2.2
> hardware : x86
> OSversion : win_nt_4.0
> priority : 4
> bugtraqID : 0
> dateCreated : 2000-05-09 04:16:16.0
> dateEvaluated : 2000-07-10 10:51:38.1
>

java-programmer >> [RFE] Access to Field, Method and Constructor without the use of Strings >> description : A DESCRIPTION OF THE REQUEST :
>> It should be possible to obtain references to Field, Method and
>> Constructor objects without the use of strings. Proposed syntax:
>>
>> // Assuming the following class
>> public class Foo {
>> String bar;
>> public Foo(String bar) {
>> this.bar = bar;
>> }
>> public void fly(String to) {
>> bar = to;
>> }
>> }
>>
>> Field fooBarField = Foo.class.bar.field;
>> Method fooFlyMethod = Foo.class.fly.method(new Object[]{String.class});
>> Constructor fooConstructor = Foo.class.constructor(new
>> Object[]{String.class});

I think it's a good idea, too.

java-programmer >> [RFE] Access to Field, Method and Constructor without the use of Strings "Gordon Beaton" skribis:

> On Thu, 18 Sep 2003 12:53:09 +0200, Carl Rosenberger wrote:
> > The existance of the field/method/constructor could be checked
> > during compile time. Typos would no longer be possible.
>
> It could only be checked at compile time if the compiler has access to
> the class in question.
>
> And if that's the case, you can use "regular" syntax to access the
> fields and get the checking you're asking for, without using
> reflection at all.

Think of an API, which works by reflection.

(S.O.D.A., which Carl mentioned, is such one.)

While _you_ know the structure of the classes,
on which to work, the API-implementation does
not (and can't, since they are compiled seperately).
So it is not possible to use "regular syntax".

You have to give the names of the Fields to
the API - or the Field-Objects.
Now, you'll have to use Strings por specifiing
them - and typos will be catched first in runtime.

With Carl's proposal, you could give Field-Objects,
simply specifiing the name.

Paul

(Please forgive my bad english - I normally
only write in german and Esperanto newsgroups.)

java-programmer >> [RFE] Access to Field, Method and Constructor without the use of Strings Carl Rosenberger wrote:
> > Hi Carl Rosenberger,
> >
> > Thank you for using our bug submit page. There may be merit to
> > your request for feature enhancement (RFE). I would suggest
> > that you first post this to a newsgroup and request comment from
> > other java developers.
> >
> > You can view a list of Java newsgroups at:
> >
> > http://java.sun.com/aboutJava/newsgroups.html
> >
> >
> > Based on the responses, please feel free to submit a new RFE
> > containing a link to the newsgroup. Thank you for your time.

Hi all,

following the above directions, I just submitted another
RFE (the third time) to the Java bug database.

I would really appreciate further "+1" comments in this
thread, should anyone else be interested to see this
feature.

It's a very small addition to the compiler and I know,
the merit for dynamic programming would be great. We
would really love to see the feature to be able to
provide the first completely typesafe object querying
system:
http://sourceforge.net/projects/sodaquery/

Thanks!

Cheers,
Carl

java-programmer >> [RFE] Access to Field, Method and Constructor without the use of Strings Carl Rosenberger wrote:
> Carl Rosenberger wrote:
>
> It's a very small addition to the compiler and I know,
> the merit for dynamic programming would be great. We
> would really love to see the feature to be able to
> provide the first completely typesafe object querying
> system:
> http://sourceforge.net/projects/sodaquery/
>
Hi,

I think that the mentioned addition to the syntax would be very useful
not only for query systems. I would lead to a much more "hygienical"
code anywhere you make heavy use of metadata.

Frank

P.S. +1

java-programmer >> [RFE] Access to Field, Method and Constructor without the use of Strings Carl Rosenberger schrieb:

> I submitted the following RFE to Sun's RFE page.

[...]

> Field fooBarField = Foo.class.bar.field;
> Method fooFlyMethod = Foo.class.fly.method(new Object[]{String.class});
> Constructor fooConstructor = Foo.class.constructor(new Object[]{String.class});
>
> There are other possible options for the syntax. I would just like to see
> this principally possible.

I think the qualifier .class. is a good idea. It ensures compatibility
to accessible fieldnames.

An other syntax:

Foo.class.fields.bar;

Foo.class.methods.fly (new Object[] {String.class});

I think this syntax is easier to read. fields and methods are like
"collections" (see below my extensions)

[...]
> JUSTIFICATION :
> The existance of the field/method/constructor could be checked during compile
> time. Typos would no longer be possible.

But why? Reflection (scripting) is a runtime checked behavior.

> A notation without strings could be very easily refactored by IDEs.

ACK.

> The possibility to get Method objects without strings, would encourage many
> developers to use them for more dynamic programming and would result in lots
> of more flexible libraries for the Java platform.

In addition string queries could by usefull:

Foo.class.fields ("foo");

or:

public Object get (String fieldName)
throws // Foo.class.fields (fieldName):
SecurityException, NoSuchFieldException,
// .get (this):
IllegalArgumentException, IllegalAccessException
{
return Foo.class.fields (fieldName).get (this);
}

IMHO this is a little problem: We have a bunch of exceptions for a
single field access.

Next example (with my syntax):

public static Object invoke (Object obj, String method)
throws // Foo.class.methods (method, null):
SecurityException, NoSuchMethodException,
// .invoke (obj, null)
IllegalAccessException, IllegalArgumentException,
InvocationTargetException

{
return Foo.class.methods (method, null).invoke (obj, null);
}

Five exceptions (ok +2: NPE and ExceptionInInitializerError), phew.
But much easier than the current reflection api.

> Thanks in advance for your attention and for positive comments.

+1 :-)

regards,
josh (sorry for my bad english)
--
Sollte beim Waschen der W鋝che diese absolut nicht weiss werden,
k鰊nte es sich um Buntw鋝che handeln.
[Haushaltstips - f黵 den n鋍hsten Tip eine Antwort provozieren...]

java-programmer >> [RFE] Access to Field, Method and Constructor without the use of Strings Aljoscha Rittner wrote:
> Carl Rosenberger schrieb:

> > I submitted the following RFE to Sun's RFE page.

> [...]
>
> > Field fooBarField = Foo.class.bar.field;
> > Method fooFlyMethod = Foo.class.fly.method(new Object[]{String.class});
> > Constructor fooConstructor = Foo.class.constructor(new Object[]{String.class});
> >
> > There are other possible options for the syntax. I would just like to see
> > this principally possible.

> An other syntax:
> Foo.class.fields.bar;
> Foo.class.methods.fly (new Object[] {String.class});
>
> I think this syntax is easier to read. fields and methods are like
> "collections" (see below my extensions)

This was my idea.

We access all members, not only public?!

> In addition string queries could by usefull:
> Foo.class.fields ("foo");

right, but:
Foo.class.getDeclaredField("foo");
is nearly the same, so better add less.

Or get the whole bunch:
Field[] f = Foo.class.fields
Methods[] m = Foo.class.methods
Constructor[] c = Foo.class.constructors
...
This seems to change the language to much? And doesn't
help so much as the changes above:
Foo.class.fields.bar, Foo.class.methods.fly

+1

Peter

java-programmer >> [RFE] Access to Field, Method and Constructor without the use of Strings "Aljoscha Rittner" skribis:

> Carl Rosenberger schrieb:
>
> > I submitted the following RFE to Sun's RFE page.
>
> [...]
>
> > Field fooBarField = Foo.class.bar.field;
> > Method fooFlyMethod = Foo.class.fly.method(new Object[]{String.class});
> > Constructor fooConstructor = Foo.class.constructor(new Object[]{String.class});
> >
> > There are other possible options for the syntax. I would just like to see
> > this principally possible.
>
> I think the qualifier .class. is a good idea. It ensures compatibility
> to accessible fieldnames.
>
> An other syntax:
>
> Foo.class.fields.bar;
>
> Foo.class.methods.fly (new Object[] {String.class});

I would like not using any "new", since "new"
is evaluated at runtime (and we want compile-time
checks).

Method fooFlyMethod = Foo.class.fly.method(String);
Constructor fooConstructor = Foo.class.constructor(String);

or

Foo.class.methods.fly(String);

> I think this syntax is easier to read. fields and methods are like
> "collections" (see below my extensions)
>
> [...]
> > JUSTIFICATION :
> > The existance of the field/method/constructor could be checked during compile
> > time. Typos would no longer be possible.
>
> But why? Reflection (scripting) is a runtime checked behavior.

For only runtime you won't need a new syntax.

The idea (as I understands it) is to enable
compile-time-checking, wherever possible.

(It should not disable the runtime-checking, which
is necessary anyway.)

> > A notation without strings could be very easily refactored by IDEs.
>
> ACK.
>
> > The possibility to get Method objects without strings, would encourage many
> > developers to use them for more dynamic programming and would result in lots
> > of more flexible libraries for the Java platform.
>
> In addition string queries could by usefull:
>
> Foo.class.fields ("foo");

For this already exists

Foo.class.getDeclaredField("foo");

and

Foo.class.getField("foo");

I see no need to use another Syntax with
only slightly less typing.

Paul
PS: +1

java-programmer >> [RFE] Access to Field, Method and Constructor without the use of Strings >Carl Rosenberger wrote:
>> > Hi Carl Rosenberger,
>> >
>> > Thank you for using our bug submit page. There may be merit to
>> > your request for feature enhancement (RFE). I would suggest
>> > that you first post this to a newsgroup and request comment from
>> > other java developers.
>> >
>> > You can view a list of Java newsgroups at:
>> >
>> > http://java.sun.com/aboutJava/newsgroups.html
>> >
>> >
>> > Based on the responses, please feel free to submit a new RFE
>> > containing a link to the newsgroup. Thank you for your time.
>
>Hi all,
>
>following the above directions, I just submitted another
>RFE (the third time) to the Java bug database.
>
>I would really appreciate further "+1" comments in this
>thread, should anyone else be interested to see this
>feature.

+1

java-programmer >> [RFE] Access to Field, Method and Constructor without the use of Strings Carl Rosenberger schrieb:
[...]
> I would really appreciate further "+1" comments in this
> thread, should anyone else be interested to see this
> feature.

+1

(Sorry 4 days without internet)

Byte theo

java-programmer >> [RFE] Access to Field, Method and Constructor without the use of Strings Carl Rosenberger wrote:
>
> I would really appreciate further "+1" comments in this
> thread, should anyone else be interested to see this
> feature.
>
> It's a very small addition to the compiler and I know,
> the merit for dynamic programming would be great. We
> would really love to see the feature to be able to
> provide the first completely typesafe object querying
> system:
> http://sourceforge.net/projects/sodaquery/

Hi Carl,

At this point, I have to give you a -1.

I think you need to provide more general arguments for a feature that changes the
language.

Object querying has very limited use and doesn't justify a language change.

Dynamic programming could be more general use, but I have serious doubts about it.

You're basically introducing a form of function pointers and variable pointers to Java.
This is definitely not OO programming.

It only supports partial type safety ... for the caller. The called methods would have
no type safety. They would receive anonymous references, to Method, Field, Constructor
objects.

I don't see dynamic references of this type as needed for Java. I find Java effective
for system programming as is.

--
Lee Fesperman, FirstSQL, Inc. (http://www.firstsql.com)
==============================================================
* The Ultimate DBMS is here!
* FirstSQL/J Object/Relational DBMS (http://www.firstsql.com)

java-programmer >> [RFE] Access to Field, Method and Constructor without the use of Strings Lee Fesperman wrote:
> > I would really appreciate further "+1" comments in this
> > thread, should anyone else be interested to see this
> > feature.
>
> At this point, I have to give you a -1.

Hi Lee,

I didn't expect anything else from you since you have
always been putting down all my postings.

I don't think we would do eachother any good with another
"Your database sucks." "No yours!" thread.

Coexistence should be our goal. SQL certainly has a future
and I think that Java method calls within an SQL query
principally are a good idea. The Evaluation/Callback feature
in S.O.D.A. is designed to make this possible also, when we
start building an SQL layer on top of S.O.D.A. It would
be nice if we would support very similar SQL dialects in
the future.

We both provide native Java engines so we will both benefit,
if Java get's a greater share as an accepted standard as
the No.1 database stored procedure language.

> I think you need to provide more general arguments for
> a feature that changes the language.

The feature does not change the language, it only provides
a design-time shortcut for:

try {
Class#getDeclaredField("");
} catch (NoSuchFieldException e) {
// Handling not necessary since the
// compiler ensures the field is there.
}

Changes to VMs will not be necessary, only the above small
addition would have to be introduced to the compiler. I
would estimate that to be less than an hour of work.

> Object querying has very limited use

If you say so.

Funny, just yesterday someone posted to our newsgroup, that
he would like to see the feature I am talking about, without
the knowledge of this thread here. I will attach his message
to the end of this one.

The idea behind object queries:
They provide an abstraction layer as a base for other querying
systems like SQL, OQL, XPath, XQuery, JDOQL. With a common
object query system it would be possible to reuse multiple query
language parsers for all of the above query languages. All
parsers create a similar query expression tree so why not try
to set a standard at the lowest level possible? That would free
vendors from the work to write parsers themselves. Just by
implementing one standard they could support all the above query
languages. I do have some hope that Prevayler, OJB, and Hibernate
also will jump in on S.O.D.A., since I hear from them that they
are interested. I would love to share the work on query language
layers with these open source products.

> and doesn't justify a language change.

The comments from the other people here come from completely
different areas, where dynamic programming is used.

I am just trying to provide one single concrete example of a
benefit.

All the best for FirstSQL!

Cheers,
Carl
Carl Rosenberger
db4o - database for objects - http://www.db4o.com

and here is the posting to our newsgroup:

"Patrick Sager" <email***@***.com> wrote in message news:bkpnqf$n1v$email***@***.com...
> Hello
>
> I'm currently evaluating db4o and I like it very much, especially its ease
> of use.
>
> But I think, the following improvement could make it even better:
>
> 1. In the trace output, there are no indications, how a query is
> evaluated. Moreover if a column (e.g. in the descendent() method) is
> misspelled, there's no error, warning or exception. The query just returns
> nothing. To avoid the possibility of field misspelling, you could support a
> parameter of type java.lang.reflect.Field. Could you also print out a
> warning, if a field wasn't found?
>
> 2. If in the evaluate method the candidate is an actual descendent and
> he is excluded, the parent should also be excluded.
>
> 3. Support a constrain on a specific array field (e.g.
> descendent("myArray[5]").constrain(42).equal()).
>
> 4. If browsing the ObjectSet and other db4o classes in the debugger, it
> seems, that the member variables are obfuscated. And it's really hard to
> find out, what they mean.
>
> Best regards
> -- Pat
>
>

java-programmer >> [RFE] Access to Field, Method and Constructor without the use of Strings "Carl Rosenberger" skribis:
> Lee Fesperman wrote:
[...]
> > I think you need to provide more general arguments for
> > a feature that changes the language.
>
> The feature does not change the language, it only provides
> a design-time shortcut for:

It _is_ a (small) addition to the language, but
in a backwards-compatible way.

> try {
> Class#getDeclaredField("");
> } catch (NoSuchFieldException e) {
> // Handling not necessary since the
> // compiler ensures the field is there.
> }

I think, better would be
---
try {
Class#getDeclaredField("");
} catch (NoSuchFieldException e) {
throw new NoSuchFieldError(e);
}
---

since there could be a difference
between runtime and compiletime (new
Class version, ...)

(And the "ignore" does not work, since then
the field-variable may be not initialized.)

Paul

java-programmer >> [RFE] Access to Field, Method and Constructor without the use of Strings Carl Rosenberger wrote:
>
> Lee Fesperman wrote:
> > > I would really appreciate further "+1" comments in this
> > > thread, should anyone else be interested to see this
> > > feature.
> >
> > At this point, I have to give you a -1.
>
> Hi Lee,
>
> I didn't expect anything else from you since you have
> always been putting down all my postings.
>
> I don't think we would do eachother any good with another
> "Your database sucks." "No yours!" thread.

I will say that a database newsgroup is more appropriate for database issues like that.
I am discussing this purely as a Java issue.

I do object to your characterizations, though. I always try to make my remarks
substantive.

> > I think you need to provide more general arguments for
> > a feature that changes the language.
>
> The feature does not change the language...

No, you are wrong. It is a language change.

> Changes to VMs will not be necessary, only the above small
> addition would have to be introduced to the compiler. I
> would estimate that to be less than an hour of work.

I don't care if it takes 5 minutes. My issue is whether it is an appropriate change to
the language.

> > Object querying has very limited use
>
> If you say so.

Seems to be the crux of the matter.

> The idea behind object queries:
> They provide an abstraction layer as a base for other querying
> systems like SQL, OQL, XPath, XQuery, JDOQL. With a common
> object query system it would be possible to reuse multiple query
> language parsers for all of the above query languages. ...

I don't see that. You are mixing declarative and navigational languages.

> > and doesn't justify a language change.
>
> The comments from the other people here come from completely
> different areas, where dynamic programming is used.
>
> I am just trying to provide one single concrete example of a
> benefit.

I know. I'm just saying that you need to present more convincing arguments for this.
The other posters haven't either. I presented arguments against this use (which you
snipped).

> All the best for FirstSQL!

Thanks. I wish you well in your ventures.

No ill will intended. If you check back on my postings on cljp, you'll see that I am
quite conservative about changes to the Java language.

--
Lee Fesperman, FirstSQL, Inc. (http://www.firstsql.com)
==============================================================
* The Ultimate DBMS is here!
* FirstSQL/J Object/Relational DBMS (http://www.firstsql.com)

java-programmer >> [RFE] Access to Field, Method and Constructor without the use of Strings Lee Fesperman wrote:
> > The idea behind object queries:
> > They provide an abstraction layer as a base for other querying
> > systems like SQL, OQL, XPath, XQuery, JDOQL. With a common
> > object query system it would be possible to reuse multiple query
> > language parsers for all of the above query languages. ...
>
> I don't see that. You are mixing declarative and navigational languages.

That's what your database engine does also:
It parses SQL and creates an object representation to be
processed by your query processor code.

A standard for the first step would reduce the necessary
implementation work for database products that don't
support SQL yet.

Kind regards,
Carl
Carl Rosenberger
db4o - database for objects - http://www.db4o.com