headers
Lars Heuer | 1 Oct 2006 15:46
Favicon

Method

Hi all,

Now that we have the static method

    Method.valueOf(String)

I wonder if it makes sense to make the Method constructors private. I
think it's unlikely that someone wants to create a non-standard
Method.
If the constructors are private we can compare Method instances by
reference which should be a lot faster than the equals(Object) method.

Thoughts?

Best regards,
Lars
--

-- 
http://www.semagia.com
Permalink | Reply | 7 comments |
headers
Jerome Louvel | 1 Oct 2006 19:20

RE: Method


Hi Lars,

In the current state, the "description" (from Metadata super class) and the
"uri" property could be customized for the same method. Therefore, unless we
remove those properties or forbid their setting, it won't be possible to
compare simple object reference for equality.

Best regards,
Jerome  

> -----Message d'origine-----
> De : Lars Heuer [mailto:heuer <at> semagia.com] 
> Envoyé : dimanche 1 octobre 2006 15:47
> À : discuss <at> restlet.tigris.org
> Objet : Method
> 
> Hi all, 
> 
> Now that we have the static method 
> 
>     Method.valueOf(String) 
> 
> I wonder if it makes sense to make the Method constructors private. I 
> think it's unlikely that someone wants to create a non-standard 
> Method. 
> If the constructors are private we can compare Method instances by 
> reference which should be a lot faster than the 
> equals(Object) method. 
>
(Continue reading)

Permalink | Reply | 6 comments |
headers
Lars Heuer | 2 Oct 2006 09:42
Favicon

Re: Method

Hi Jerome,

> In the current state, the "description" (from Metadata super class) and the
> "uri" property could be customized for the same method.

Okay, I overlooked that. :/

>  Therefore, unless we
> remove those properties or forbid their setting, it won't be possible to
> compare simple object reference for equality.

I see. I wonder if the properties are useful for the Methods.
Comparing by identity is not soooo important, but who actually uses
Method.getDescription() or Method.getURI()?

Best regards,
Lars
--

-- 
http://www.semagia.com
Permalink | Reply | 5 comments |
headers
Jerome Louvel | 2 Oct 2006 17:00

RE: Method


Hi Lars,

These properties are in fact in the super Metadata class, and used for
example with Status instances to display error pages with meaningful
descriptions and hyperlinks. 

Anyone else has an opinion on this?

Best regards,
Jerome  

> -----Message d'origine-----
> De : Lars Heuer [mailto:heuer <at> semagia.com] 
> Envoyé : lundi 2 octobre 2006 09:42
> À : Jerome Louvel
> Objet : Re: Method
> 
> Hi Jerome, 
> 
> > In the current state, the "description" (from Metadata 
> super class) and the 
> > "uri" property could be customized for the same method. 
> 
> Okay, I overlooked that. :/ 
> 
> >  Therefore, unless we 
> > remove those properties or forbid their setting, it won't 
> be possible to 
> > compare simple object reference for equality.
(Continue reading)

Permalink | Reply | 4 comments |
headers
Lars Heuer | 2 Oct 2006 17:30
Favicon

Re: Method

Hi Jerome,

> These properties are in fact in the super Metadata class, and used for
> example with Status instances to display error pages with meaningful
> descriptions and hyperlinks. 

Yes, I know and for Status it makes sense.

I think Method should not be derived from Metadata because it doen't
adds a value IMO.

To avoid confusion if the Method can be compared by identity or not,
we should convert Method (back?) to an Enum. Enums can always be
compared by identity, so it limits confusion if Method is comparable
by identity or not.

Best regards,
Lars
--

-- 
http://www.semagia.com
Permalink | Reply | 3 comments |
headers
Jerome Louvel | 2 Oct 2006 17:42

RE: Method


Hi Lars,

> I think Method should not be derived from Metadata because it doen't 
> adds a value IMO. 
>
> To avoid confusion if the Method can be compared by identity or not, 
> we should convert Method (back?) to an Enum. Enums can always be 
> compared by identity, so it limits confusion if Method is comparable 
> by identity or not. 

We predefined the standard HTTP and WebDAV methods, but nothing in REST or
HTTP prevents the user from creating new ones if needed. If we think about
the mapping of other protocols to the API which may also require new
methods. 

If a user has to create a "QUERY" method for example, he could use the
Method.valueOf() method, but would still need to compare it via "equals()"
because another valid instance could have been created somewhere else in the
code. Enums work fine only if the list of items is fully know at compil
time, which unfortunately is not our case.

Thanks,
Jerome
Permalink | Reply | 2 comments |
headers
Lars Heuer | 3 Oct 2006 18:42
Favicon

Re: Method

Hi Jerome,

[...]
> We predefined the standard HTTP and WebDAV methods, but nothing in REST or
> HTTP prevents the user from creating new ones if needed. If we think about
> the mapping of other protocols to the API which may also require new
> methods. 

You're absolutly right. Sorry for this not well thought silly
suggestion. :)

Best regards,
Lars
--

-- 
http://www.semagia.com
Permalink | Reply | 1 comment |
headers
Jerome Louvel | 3 Oct 2006 18:56

RE: Method

No problem Lars, I've been through this line of thought several times myself
when I wanted to leverage the enums by mixing them with classes :-)

Best regards,
Jerome  

> -----Message d'origine-----
> De : Lars Heuer [mailto:heuer <at> semagia.com] 
> Envoyé : mardi 3 octobre 2006 18:43
> À : Jerome Louvel
> Objet : Re: Method
> 
> Hi Jerome, 
> 
> [...] 
> > We predefined the standard HTTP and WebDAV methods, but 
> nothing in REST or 
> > HTTP prevents the user from creating new ones if needed. If 
> we think about 
> > the mapping of other protocols to the API which may also 
> require new 
> > methods. 
> 
> You're absolutly right. Sorry for this not well thought silly 
> suggestion. :) 
> 
> Best regards, 
> Lars 
> -- 
> http://www.semagia.com
(Continue reading)

Permalink | Reply | 0 comments |
headers
Sean Landis | 3 Oct 2006 21:03
Picon

Re: Surprising interaction between Call status and output


Jerome Louvel <contact <at> noelios.com> writes:

> 
> 
> Hi Sean,
> 
> I've fixed the issue in SVN. Thanks for the feed-back!
> 
> Best regards,
> Jerome 

Thanks Jerome. I was hoping to get this change so
I checked out the HEAD and tried to build and got the following:

test:
    [junit] Running com.noelios.restlet.test.NoeliosTestSuite
    [junit] Tests run: 3, Failures: 1, Errors: 0, Time elapsed: 0.593 sec

BUILD FAILED
/home/slandis/RestletDev/restlet/build.xml:528: Test
com.noelios.restlet.test.NoeliosTestSuite failed

Is the SVN currently unstable, or am I missing a step?

Thanks,
Sean

> 
> > -----Message d'origine-----
(Continue reading)

Permalink | Reply | 1 comment |
headers
Jerome Louvel | 3 Oct 2006 23:51

RE: Surprising interaction between Call status and output


Hi Sean,

It was indeed instable for a couple of hours yesterday but passes all the
tests now. However, the Servlet adapter is currently broken so I suggest
that you wait a bit more for the beta 19 release, hopefully released this
week.

Best regards,
Jerome  

> -----Message d'origine-----
> De : news [mailto:news <at> sea.gmane.org] De la part de Sean Landis
> Envoyé : mardi 3 octobre 2006 21:03
> À : discuss <at> restlet.tigris.org
> Objet : Re: Surprising interaction between Call status and output
> 
> 
> 
> Jerome Louvel <contact <at> noelios.com> writes: 
> 
> > 
> > 
> > Hi Sean, 
> > 
> > I've fixed the issue in SVN. Thanks for the feed-back! 
> > 
> > Best regards, 
> > Jerome 
>
(Continue reading)

Permalink | Reply | 0 comments |

Gmane