ruby-dev summary 24298-24353

R

Robert Klemme

trans. (T. Onoma) said:
Here's one related to a recent thread:

class Object
def supers(klass=self.class.superclass)
raise ArgumentError if ! self.class.ancestors.include?(klass)
Functor.new do |meth, *args|
klass.instance_method(meth).bind(self).call(*args)
end
end
end

Hmm, maybe should cache the functor for efficiency.

Might not be a good idea since the method can change. Currently I don't know
a way to detect that change as those method methods always return new
instances.

Apart from that I still think that explicit super class method invocation
other than a method invocing its own super implementation is a code smell
that indicates the need for a refactoring.

Cheers

robert
 
T

trans. (T. Onoma)

Might not be a good idea since the method can change. Currently I don't
know a way to detect that change as those method methods always return new
instances.

Right. Makes me wish Ruby had an light-weight object class.
Apart from that I still think that explicit super class method invocation
other than a method invocing its own super implementation is a code smell
that indicates the need for a refactoring.

Hmm... I might say the same thing about instance_variable_set. In fact, one
might go further and say the same about class_eval, instance_eval,
define_method, etc. --in certain way all these "meta features" reek of code
smell! But it's all about the use case. There are core-language related use
cases for which these are must haves. I dare so, though, it might be better
if these features added via #require, rather then always be present.

T.
 
R

Robert Klemme

trans. (T. Onoma) said:
Right. Makes me wish Ruby had an light-weight object class.

What exactly do you want this for? What should it do?
Hmm... I might say the same thing about instance_variable_set. In fact, one
might go further and say the same about class_eval, instance_eval,
define_method, etc. --in certain way all these "meta features" reek of code
smell! But it's all about the use case. There are core-language related use
cases for which these are must haves. I dare so, though, it might be better
if these features added via #require, rather then always be present.

I'd certainly put these into two different categories (different smells,
if you like). There are things that you just can't do without eval,
class_eval, instance_eval etc. But you usually can set instance variables
through normal setters (and you shouldn't if they are not present) and you
can do refactoring to access special functionality in a method. So these
are really two cups of tea.

Regards

robert
 
T

trans. (T. Onoma)

What exactly do you want this for? What should it do?

They have one in Evil. Essentially a Kernel-less object, which is good for
cases like this.

T.
 
A

Ara.T.Howard

They have one in Evil. Essentially a Kernel-less object, which is good for
cases like this.

where is Evil downloaded?

-a
--
===============================================================================
| EMAIL :: Ara [dot] T [dot] Howard [at] noaa [dot] gov
| PHONE :: 303.497.6469
| A flower falls, even though we love it;
| and a weed grows, even though we do not love it.
| --Dogen
===============================================================================
 
T

trans. (T. Onoma)

where is Evil downloaded?

On Rubyforge.

For just the evil.rb file:
http://rubyforge.org/cgi-bin/viewcv...oot=evil&content-type=text/vnd.viewcvs-markup

For the whole cvs:
http://rubyforge.org/cgi-bin/viewcvs/cgi/viewcvs.cgi/cvs_root.tar.gz?tarball=1&cvsroot=evil


And here she is:

# Like Object, but this provides no methods at all.
# You can derivate your own Classes from this Class
# if you want them to have no preset methods.
#
# obj = KernellessObject.new
# obj.methods # ~> NoMethodError
class KernellessObject
def self.new
obj = ::Object.new
obj.class = self
return obj
end

self.superclass = nil
end


Seems to be that this is a bit more than just "Kernelless", this looks more
like the hollow ShellOfObject :)

T.
 
T

trans. (T. Onoma)

I'd certainly put these into two different categories (different smells,
if you like). There are things that you just can't do without eval,
class_eval, instance_eval etc. But you usually can set instance variables
through normal setters (and you shouldn't if they are not present) and you
can do refactoring to access special functionality in a method. So these
are really two cups of tea.

Oh, I agree. I would suggest a different sets. E.g.

require 'evaluators'
eval
class_eval
instance_eval

require 'instigators' # ;)
instance_variable_get
instance_variable_set
const_get
const_set

and so one.

T.
 
Y

Yukihiro Matsumoto

Hi,

Sorry for being late.

In message "Re: ruby-dev summary 24298-24353"

|01 set_trace_func proc{ |e, f, l, m, b, k|
|02 puts "#{e}, #{f}, #{l}, #{m}, #{k}" if ! b
|03 }
|04
|05 module T
|06 # setup
|07 class Test
|08 def initialize; @example = true; end
|09 def test; "Okay!"; end
|10 end
|11 end
|12
|13 t = T::Test.new
|14 t.test
|15 t.test
|
|Which returns:
|
| end, t.rb, 7, , false
| end, t.rb, 5, , false
|
|I'm not sure why this would be. Isn't there always a context? Also I find the
|line numbers odd (I added for easy reading), those mark where the 'class'
|event occurs.

What is your concern. klass being false instead of nil? Is it a
problem for you? I could easily change it to nil, but have not really
been motivated.

Also, the "end" line does not have any AST node, so that the tracer
passes line numbers for corresponding start line (i.e. "class" for
this case).

matz.
 
T

trans. (T. Onoma)

On Tuesday 19 October 2004 09:39 pm, Yukihiro Matsumoto wrote:
| Sorry for being late.

No rush. Way too much to do all 'round it seems. But thank you for getting
back to me.

| What is your concern. klass being false instead of nil? Is it a
| problem for you? I could easily change it to nil, but have not really
| been motivated.

I don't understand why it doesn't return the class of the outer scope --and
it's binding too. In this case it would be TOPLEVEL_BINDING and class Object,
I believe.

| Also, the "end" line does not have any AST node, so that the tracer
| passes line numbers for corresponding start line (i.e. "class" for
| this case).

Hmm. Well, guess there's no fix for that.

Thanks,
T.
 
Y

Yukihiro Matsumoto

Hi,

In message "Re: ruby-dev summary 24298-24353"

|I don't understand why it doesn't return the class of the outer scope --and
|it's binding too. In this case it would be TOPLEVEL_BINDING and class Object,
|I believe.

trace_func receives 6 parameters:

event: type of event which calls trace_func
file: file name of the place of event
line: line number of the place of event
method: name of the method surrounding the place of event
binding: binding at the place of event (if any)
klass: class that defines calling method (for call event),
or false value if event happened outside of any method

This in the current behavior, "method" and "klass" parameters are left
blank for the "end" event, caused by class/module statement outside of
methods. Do you want to change these? For any reason?

The "binding" parameter is bit more complicated. The "end" events are
caused just in the middle of scope transitions (class scope to outer
scope), so that I had hard time to determine which binding to return.
Besides that, all know usage of "end" event do not require any
information other than the event position, I haven't been motivated
much to change the behavior, making interpreter more complex.

matz.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,951
Messages
2,570,113
Members
46,698
Latest member
alexxx

Latest Threads

Top