Asp Forum - Re: Controlled block variables

T. Onoma

11/26/2003 8:49:00 AM

On Wednesday 26 November 2003 09:10 am, Guy Decoux wrote:

> I'm agree with David : this thread has *nothing* to do with ruby-core.
>
> Your subject is appropriated for ruby-talk : if it's ignored, like you
> say, this is perhaps because there is a good reason

Then why isn't it being ignored on core? D.N.C.

Are you implying that it is stupid, dumb and unworthy? Then speak for youself.
I believe such matters tend to get ignored on ruby-talk b/c there is too much
"filter-noise" there for more indepth and speculative analyses to shine
through, among other reasons --like constant nay-sayers who bark down an idea
for no other reason then it's outside the "general norms".

This belongs on ruby-talk? Fine...

For those interested, see reference core:1787, and start of thread 1751

http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby...
http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby...

-t0

37 Answers

ts

11/26/2003 8:57:00 AM

>>>>> "T" == T Onoma <transami@runbox.com> writes:

T> Are you implying that it is stupid, dumb and unworthy?

You want to change this

a = 12

def b
p a
end

Nobody has a problem with this, except you, perhaps because you are
learning ruby ?

ruby-core:1728 and ruby-talk:86133 are another good examples

Guy Decoux

T. Onoma

11/26/2003 9:40:00 AM

On Wednesday 26 November 2003 09:56 am, ts wrote:
> >>>>> "T" == T Onoma <transami@runbox.com> writes:
>
> T> Are you implying that it is stupid, dumb and unworthy?
>
> You want to change this
>
> a = 12
>
> def b
> p a
> end
>
> Nobody has a problem with this, except you, perhaps because you are
> learning ruby ?

No and Always.

No, because that's not what I orignially presented. I offered an idea that
would allow eval an *exception* to reach up to that scope, not the above def.
I later asked, why it was the def could not see a in this case, and had some
interesting return dialog, to which I then added an idea on how it could
work. So other then for eval, I never suggested that Ruby be changed to do
that. I was only disscussing some interesting notions on the topic.

And I am Always learning Ruby, since my conversion in 2001. Perhaps you are
not ?

-t0

P.S. You know, I don't really like being antagonistic. But it is really
bothersome to have to deal such negativity. If you find the concept somehow
flawed then present an intelligent counter argument, don't just berail me for
having a notion all my own. And if you don't feel the disccussion belongs on
core then just say "Hey, guys, this should probably be on ruby-talk, can we
move it there?" Or, "Perhaps another list would be a good idea..." Rather
then being so accustional, as if we had violated some hallowed law.

Pit Capitain

11/26/2003 11:06:00 AM

Hi T,

maybe you can make use of "define_method" as in

class X
def self.add_method name, value
eval "define_method name, proc{value}"
end
end

X.add_method :array, [1, 2, 3]
X.add_method :hash, {1=>"A", 2=>"B"}

x = X.new

p x.array # => [1, 2, 3]
p x.hash # => {1=>"A", 2=>"B"}

HTH

Regards,
Pit

Dan Doel

11/26/2003 2:57:00 PM

I actually have wondered in the past why there isn't an #eval that takes
a proc (other than as a binding).

There's #instance_eval and #module_eval/#class_eval for replacing the
object scope of a Proc, but
there's no way you can do this:

def foo
a = 4
b = 5

proc { p a; p b }
end

def bar(p)
a = 7
b = 8

eval p
end

bar(foo)

and get 7 and 8 printed. I realize that Proc objects are closures, but
since they're also representations
of sections of code, it would be interesting to be able to switch them
to dynamic scoping for all the
benefits and problems that causes, and using #eval seems like a fairly
clean way of denoting that.

Of course, I don't know how big a change that would require for Proc and
the Ruby interpreter. I'm
not familiar with the internals of either.

Regards.

- Dan

T. Onoma

11/26/2003 3:07:00 PM

On Wednesday 26 November 2003 09:56 am, ts wrote:

> ruby-core:1728 and ruby-talk:86133 are another good examples

<quote source="ruby-talk:86133">
Except that it means more work for interpreter to enforce rule of not allowing
it. Would you say the same thing about this?

class WhatDoIDo

def dothis
print "Nope"
end

def dothis
print "Yep"
end

end
<quote>

To think this makes me look like a nubie! HAH! I think you made too much of an
assumption and thus did not really understand me. perhaps other did not
understand either, so I will clear up.

The point was that this is completely allowed. The previous def just gets
replaced by the next one. This was in response to

> Agreed 100% - I see no reason for allowing several hooks
> in the same class.

Does it make sense now?

As for 1728, I really had just never done that before. I have always defined
my classes prior to substantiating any object. Never even occured to me that
if I susbsequently altered my classes that all my objects would change too.

-t0

ts

11/26/2003 3:11:00 PM

>>>>> "T" == T Onoma <transami@runbox.com> writes:

>> Agreed 100% - I see no reason for allowing several hooks
>> in the same class.

T> Does it make sense now?

svg% ruby -w
class A
def a:hook
end

def a:hook
end
end
^D
-:5: warning: method redefined; discarding old a:hook
svg%

p.s. : gsub!(/hook/, 'wrap')

Guy Decoux

T. Onoma

11/26/2003 4:52:00 PM

On Wednesday 26 November 2003 04:11 pm, ts wrote:

> T> Does it make sense now?
>
> svg% ruby -w
> class A
> def a:hook
> end
>
> def a:hook
> end
> end
> ^D
> -:5: warning: method redefined; discarding old a:hook
> svg%

So we should throw an error instead? I say we don't even need the warning.
So ask, should it continue to do so with the addition of hooks? (Not to
mention there are some fundemental problems with this disallowing.)

-t0

ts

11/26/2003 5:14:00 PM

>>>>> "T" == T Onoma <transami@runbox.com> writes:

T> So ask, should it continue to do so with the addition of hooks? (Not to
T> mention there are some fundemental problems with this disallowing.)

Which problems ?

Guy Decoux

T. Onoma

11/26/2003 5:26:00 PM

On Wednesday 26 November 2003 03:57 pm, Dan Doel wrote:
> I actually have wondered in the past why there isn't an #eval that takes
> a proc (other than as a binding).
>
> There's #instance_eval and #module_eval/#class_eval for replacing the
> object scope of a Proc, but
> there's no way you can do this:
>
> def foo
> a = 4
> b = 5
>
> proc { p a; p b }
> end
>
> def bar(p)
> a = 7
> b = 8
>
> eval p
> end
>
> bar(foo)
>
> and get 7 and 8 printed. I realize that Proc objects are closures, but
> since they're also representations
> of sections of code, it would be interesting to be able to switch them
> to dynamic scoping for all the
> benefits and problems that causes, and using #eval seems like a fairly
> clean way of denoting that.

this is an interesting means of code evaluation. essentially encapsulating
blocks of code to be "opened-up" (like a can of worms ;-) at other points in
execution. it is a technique quite capable of replacing methods/functions all
together. but there is a severe problem with it: it causes bad headaches with
name clashing. this is why methods are used instead. with methods you at
least know what is going into them and variables are renamed in transition.
for example what if i was using the variable x instead of a? i'd have to set
a = x, but what if i was already using a for something else, then i'd have to
move a out of the way. and so forth.

so what you end up doing instead is

def foo
a = 4
b = 5
proc { |a,b| p a; p b }
end
def bar(p)
a = 7
b = 8
p.call(a,b)
end
bar(foo)

and you'll get 7 and 8 without the problem sited above.

that said, now perhaps someone can explain to me why the #call is need? is
there some reason the interpretor can't deal with just

p(a,b)

couldn't Ruby just give precedence to proc evaluation similiar to local
precedence?

thanks Dan,
-t0

T. Onoma

11/26/2003 6:06:00 PM

On Wednesday 26 November 2003 06:14 pm, ts wrote:
> >>>>> "T" == T Onoma <transami@runbox.com> writes:
>
> T> So ask, should it continue to do so with the addition of hooks? (Not to
> T> mention there are some fundemental problems with this disallowing.)
>
> Which problems ?
>
>
> Guy Decoux

First, small problem

class A
def dolittle
print "duck"
end
def dolittle:hook # where's the super? what do i do?
print "rabbit"
end
end

A little bigger

class A
def dolittle
print "duck"
end
def dolittle:hook
super
print "rabbit"
end
end

class B < A
def dolittle:hook # am i replacing old hook? (there's no local dolittle)
super # or am i supering to old hook?
print "fox"
end
end

Much bigger problem: a library the i don't know how it works, i'm just using
it:

class L
def dolittle
print "duck"
end
def dolittle:hook
super
print "rabbit"
end
end
l = L.new
l.dolittle # => duckrabbit

no no i say, i want dolittle's "duckradditstew"!

class L
def dolittle:hook
super
print "stew!"
end
end
l.dolittle # => duckstew!

Yuk! I don't like plain duckstew.

But the worst problem of all is simply that not allowing multiple wraps, so
severely limits the capabilities of this mechinism that it would actually
have no general use whatsoever.

indeed it would actually be highly advisable NOT to ever use it b/c of the
last example given above, and would only ever be really useful for
devleopment/testing purposes alone.

(not to mention other issues with super)

-t0

comp.lang.ruby

Re: Controlled block variables

T. Onoma

ts

T. Onoma

Pit Capitain

Dan Doel

T. Onoma

ts

T. Onoma

ts

T. Onoma

T. Onoma

x Login to ForumsZone