[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.ruby

Ruby Idiom: two alternate constructors on a Value Object

List Recv

6/21/2006 9:36:00 PM

I'm having trouble discovering the correct Ruby idiom for this:

I know how to create a second constructor:

def self.from_address(address)

But, how can that constructor call private methods on the object?
I hate to force methods needed by that constructor to be public, just
so it can use it. Is there any solution?
8 Answers

Timothy Goddard

6/22/2006 6:35:00 AM

0

You can use instance_eval to execute a block in the context of an
object. This will allow you to call private methods.

listrecv@gmail.com wrote:
> I'm having trouble discovering the correct Ruby idiom for this:
>
> I know how to create a second constructor:
>
> def self.from_address(address)
>
> But, how can that constructor call private methods on the object?
> I hate to force methods needed by that constructor to be public, just
> so it can use it. Is there any solution?

gabriele renzi

6/22/2006 9:02:00 AM

0

Timothy Goddard ha scritto:
> You can use instance_eval to execute a block in the context of an
> object. This will allow you to call private methods.

or you can just use
object.send :privatemethodname, arg1, arg2, argN

Dave Burt

6/22/2006 9:33:00 AM

0

gabriele renzi wrote:
> Timothy Goddard ha scritto:
>> You can use instance_eval to execute a block in the context of an
>> object. This will allow you to call private methods.
>
> or you can just use
> object.send :privatemethodname, arg1, arg2, argN

Isn't that (using send to call a private method) deprecated?

Dave

ts

6/22/2006 9:57:00 AM

0

>>>>> "D" == Dave Burt <dave@burt.id.au> writes:

D> Isn't that (using send to call a private method) deprecated?

It's called #funcall in 1.9

moulon% ./ruby -ve 'self.send(:puts, "a")'
ruby 1.9.0 (2006-06-20) [i686-linux]
-e:1:in `BasicObject#send': private method `puts' called for main:Object (NoMethodError)
from -e:1
moulon%

moulon% ./ruby -ve 'self.funcall(:puts, "a")'
ruby 1.9.0 (2006-06-20) [i686-linux]
a
moulon%



--

Guy Decoux

List Recv

6/23/2006 1:41:00 AM

0

All these techniques are hackish, in that you need to set up an access
control means and break it.

Is there no way to mark a method as "may be called by the instance as
well as by class methods"?

Austin Ziegler

6/23/2006 12:00:00 PM

0

listrecv@gmail.com wrote:
> All these techniques are hackish, in that you need to set up an access
> control means and break it.
>
> Is there no way to mark a method as "may be called by the instance as
> well as by class methods"?

No. Because "class methods" aren't what you think they are.

You could have a flag in your class that would prevent the calling of
the initialization method more than once.

-austin

zycte

6/23/2006 3:26:00 PM

0

On 2006-06-23 13:59:38 +0200, "Austin Ziegler" <halostatue@gmail.com> said:

> listrecv@gmail.com wrote:
>> All these techniques are hackish, in that you need to set up an access
>> control means and break it.
>>
>> Is there no way to mark a method as "may be called by the instance as
>> well as by class methods"?
>
> No. Because "class methods" aren't what you think they are.

To be more specific, a class is just an object, which also follows
normal access control (public: everyone, private: me only, protected:
descendants)

Although this is very consequent, it makes it sometimes a pain, like in
your example. I also ran into this issue a while ago, I decided just to
go public with one helper initializer and by documenting it as private
in the API.

>
> You could have a flag in your class that would prevent the calling of
> the initialization method more than once.
>
> -austin

List Recv

6/26/2006 3:51:00 AM

0

I think it is an issue of implenetation versus intention.

Implementation wise, it makes sense. Class methods aren't to be viewed
as static methods of the class - they're methods of a different class,
of class Class.

Intention wise - it seems wrong to me. I should be able to mark
methods as not being part of the public interface, but usable in
constructors and other "static" methods.

Reminds me of the ol' Unix
you-can-delete-a-file-that-you-don't-have-write-permissions-to paradox.
Looking at the implementation, you can understand this (deleting a
file is not writing to it but rather to its directory). Intention
wise, it's wrong. What surprises me is that Ruby seems to go with the
OO theme of focusing on intention, not implementation.

My 2 cents.


zycte wrote:
> On 2006-06-23 13:59:38 +0200, "Austin Ziegler" <halostatue@gmail.com> said:
>
> > listrecv@gmail.com wrote:
> >> All these techniques are hackish, in that you need to set up an access
> >> control means and break it.
> >>
> >> Is there no way to mark a method as "may be called by the instance as
> >> well as by class methods"?
> >
> > No. Because "class methods" aren't what you think they are.
>
> To be more specific, a class is just an object, which also follows
> normal access control (public: everyone, private: me only, protected:
> descendants)
>
> Although this is very consequent, it makes it sometimes a pain, like in
> your example. I also ran into this issue a while ago, I decided just to
> go public with one helper initializer and by documenting it as private
> in the API.
>
> >
> > You could have a flag in your class that would prevent the calling of
> > the initialization method more than once.
> >
> > -austin