The default toString, hashCode and equals implementations

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

The default toString, hashCode and equals implementations

Marc Palmer Local
Hi,

As Graeme knows I'm just starting on my Grails journey so bear with  
me...

As a newbie it strikes me as ugly / error prone that generated domain  
classes include the source for the toString, equals and hashCode  
methods. Presumably these are needed for correct operation of  
Grails / GORM.

Doesn't exposing these inline create unnecessary ugliness and scope  
for error? Can't they be supplied (at least with these default impls)  
in an inherited base class or the Metaclass?

Cheers


---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

Reply | Threaded
Open this post in threaded view
|

Re: The default toString, hashCode and equals implementations

graemer
We're working on injecting them at compile time which will get around
this problem

Cheers
Graeme

On 6/26/06, Marc Palmer <[hidden email]> wrote:

> Hi,
>
> As Graeme knows I'm just starting on my Grails journey so bear with
> me...
>
> As a newbie it strikes me as ugly / error prone that generated domain
> classes include the source for the toString, equals and hashCode
> methods. Presumably these are needed for correct operation of
> Grails / GORM.
>
> Doesn't exposing these inline create unnecessary ugliness and scope
> for error? Can't they be supplied (at least with these default impls)
> in an inherited base class or the Metaclass?
>
> Cheers
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email