Inplace assignment

T. Onoma wrote:

But, I actually did find a better way to do it this morning, by redefining
MyClass#new to return a subclass of itself instead. Hmm…I forget, what kind
of design pattern is that?

Sounds like a factory method to me. Is there one specifically about
redefining a constructor to return a subclass? (Clever application of
the pattern, BTW.)

···


Jamis Buck
jgb3@email.byu.edu

ruby -h | ruby -e ‘a=;readlines.join.scan(/-(.)[e|Kk(\S*)|le.l(…)e|#!(\S*)/) {|r| a << r.compact.first };puts “\n>#{a.join(%q/ /)}<\n\n”’

Two classes being described as “duck similar” brings the whole thing
back to a tight bonding between class and type. At the very least,
someone who was new to the notion of duck typing, or encountered it
subsequent to having been told that two Class objects exhibited “duck
similar[ity]” precisely because they defined similar interface (which
is exactly what duck typing does not reflect), would, I expect, find
it that much harder to grasp that the point of “duck typing” is that
it offers an alternative to class-based ways of thinking about type.

This doesn’t mean that two classes can’t have similarly named
methods; it just means that there’s nothing ‘duck’-related about it.
If anything, the relation of duck typing to class objects would have
to do with their dynamic profiles, particularly as regards singleton
(class) methods.

David

···

On Mon, 15 Dec 2003, T. Onoma wrote:

On Sunday 14 December 2003 03:59 pm, David A. Black wrote:

I’m not sure what you mean by “duck similar” (the notion of duck
typing doesn’t scale well to “duck ”), but assuming you
mean a class that defines methods with the same names and arities as
another class, the best thing would probably be to do:

See, you knew exactly what I was talking about, and I only used two words!
Seems to scale fairly well :wink:


David A. Black
dblack@wobblini.net

But, I actually did find a better way to do it this morning, by redefining
MyClass#new to return a subclass of itself instead. Hmm…I forget, what kind
of design pattern is that?

If used for wrapping, this technique would only change the wraps for newly
created objects, right? Is that what we want wrapping to do?

Peter

Yes, you just have to make sure the class exists in the first place
:slight_smile: But I can't imagine what good it would do. I'm not even sure in
what sense it would be "recursive"; I think all it does is duplicate
the method search path needlessly.

no, it's not recursive.

ruby just replace the constant with the new class (and you have a message
"already initialized constant ...")

For example

svg% cat b.rb
#!/usr/bin/ruby
class A
   def a
      puts "A#a"
   end
end

class A < A
   def a
      puts "A#a1"
      super
   end
end

A.new.a
p A.ancestors
A.ancestors[1].new.a
svg%

svg% b.rb
./b.rb:8: warning: already initialized constant A
A#a1
A#a
[A, A, Object, Kernel]
A#a
svg%

Guy Decoux

Alright, a number of things related to Duck Tpying have been popping up and I
think it deserves some attention.

First off, someone inline commented Ruby Garden wiki page, DuckTypeMusings,
with disagreements on the content there. Now one may not agree, but I think a
separate comment section is the polite way to go about this --A wiki page is
not a mailing list. So I moved the comments and made some replys.

Then, along with a reproduction of Dave’s ruby-talk post on the matter, I
added an Additional Links section to the DuckTyping wiki page pointing to
DuckTypeMusings. Someone removed that section.

I assume these were done by the same person. Appearently that person has the
God given Stone Tablet on Duck Typing at thier house, cause they sure find
Musings on Duck Typing unpious.

I recently commented on how one of the problems I see with the wider adoption
of Ruby is an Elitist attitude. This Duck Typing issue is a good example of
what I’m talking about. I don’t understad why people feel it is neccessary to
CONTROL the use of this term. Just discuss it and it will take care of
itself. Otherwise people can be freightend away --they don’t feel
comfortable, b/c they have to worry too much about whether they are going
to use the proper terms in the proper manner.

Sorry if I’ve come off too strongly, I’m just trying to give a clear
conveyance of my irk over this.

T.

I’m not sure what you mean by “duck similar” (the notion of duck
typing doesn’t scale well to “duck ”), but assuming you
mean a class that defines methods with the same names and arities as
another class, the best thing would probably be to do:

See, you knew exactly what I was talking about, and I only used two
words! Seems to scale fairly well :wink:

Two classes being described as “duck similar” brings the whole thing
back to a tight bonding between class and type. At the very least,
someone who was new to the notion of duck typing, or encountered it
subsequent to having been told that two Class objects exhibited “duck
similar[ity]” precisely because they defined similar interface (which
is exactly what duck typing does not reflect), would, I expect, find
it that much harder to grasp that the point of “duck typing” is that
it offers an alternative to class-based ways of thinking about type.

Certainly you have a point, my only quibble with what you are saying is
exactly that. This is really a quibble. I was trying to convey the idea of a
replacement class having the responding methods required of the needed
context similiar to the pre-existent class it replaces, but it in no way
entails that they will have all or even nearly all the same methods. I tried
to convey this concisely by my phrase, which you appeared to understand quite
well, enough at least that you were comfortable in telling me it was a poor
choice of words. But this only affirms my intention which was to communicate
an idea, not make a definition. Morevoer, if I were to only have said
“similiar” you may have still understood me, but there would have been a
greater chance for one to ask “similiar in what way?”.

This doesn’t mean that two classes can’t have similarly named
methods; it just means that there’s nothing ‘duck’-related about it.
If anything, the relation of duck typing to class objects would have
to do with their dynamic profiles, particularly as regards singleton
(class) methods.

The later is certainly true. As to the former, if there is no relavence to
classes sharing exactly the same method names, then how can Duck Typing
even be possible? There is undoubtedly a relationship.

Actually maybe that is the source of this confusion. To me Duck Typing has two
related sides on the same coin. One is as you mention, dynamic addition (or
removal) of methods from objects. Hence “Duck Type” != Class. But secondly,
there is also the object substituion that can take place: Polymorphism, which
I believe is essenstialy what Duck Typing is about. Take this definition on
the second link I came up with in a google search:

Polymorphism is ability of objects to act depending of their run-time type.
(see: http://bepp.8m.com/english/oop/polymorphism.htm)

I think that’s the bottom line really: run-time type. That’s duck typing.
Dave just came up with a fun new name; a name I happen to really like.

T.

···

On Sunday 14 December 2003 05:25 pm, David A. Black wrote:

On Mon, 15 Dec 2003, T. Onoma wrote:

On Sunday 14 December 2003 03:59 pm, David A. Black wrote:

I have circumvented that problem. Hopefully there are no hidden catches in
what I’ve worked out. I have essentially patterned the design on Ruby’s
internal implementation of singletons. I’ll send you the code here in a bit.
It’s surprisingly small.

···

On Sunday 14 December 2003 09:54 pm, Peter wrote:

But, I actually did find a better way to do it this morning, by
redefining MyClass#new to return a subclass of itself instead. Hmm…I
forget, what kind of design pattern is that?

If used for wrapping, this technique would only change the wraps for newly
created objects, right? Is that what we want wrapping to do?

Peter


T.

Thanks! It is a Factory. I was having a hard time placing it because I tend to
think of those as separate entities from the classes they return.

···

On Sunday 14 December 2003 05:22 pm, Jamis Buck wrote:

T. Onoma wrote:

But, I actually did find a better way to do it this morning, by redefining
MyClass#new to return a subclass of itself instead. Hmm…I forget, what
kind of design pattern is that?

Sounds like a factory method to me. Is there one specifically about
redefining a constructor to return a subclass? (Clever application of
the pattern, BTW.)


T.

They weren’t.

David

···

On Mon, 15 Dec 2003, T. Onoma wrote:

Then, along with a reproduction of Dave’s ruby-talk post on the matter, I
added an Additional Links section to the DuckTyping wiki page pointing to
DuckTypeMusings. Someone removed that section.

I assume these were done by the same person.


David A. Black
dblack@wobblini.net

People generally CONTROL the incorrect usage of any expression. “Duck
similarity” is a ridiculous kidnapping of a term, when really you meant an
interface inheritence. Duck-typing is variable scoped, not class scoped: it
answers the question “Can the current variable understand the message
#some_message?”.

David
http://homepages.ihug.com.au/~naseby/

···

-----Original Message-----
From: T. Onoma [mailto:transami@runbox.com]

of Ruby is an Elitist attitude. This Duck Typing issue is a good
example of
what I’m talking about. I don’t understad why people feel it is
neccessary to
CONTROL the use of this term.

But, I actually did find a better way to do it this morning, by
redefining MyClass#new to return a subclass of itself instead. Hmm…I
forget, what kind of design pattern is that?

If used for wrapping, this technique would only change the wraps for newly
created objects, right? Is that what we want wrapping to do?

Peter

I have circumvented that problem. Hopefully there are no hidden catches in
what I’ve worked out. I have essentially patterned the design on Ruby’s
internal implementation of singletons. I’ll send you the code here in a bit.
It’s surprisingly small.

I think I may have misread the part of your post above. Did you mean that
you redefine MyClass#new to always return a subclass of Myclass,
regardless of whether there are wraps or not? I first read that you’d do
that from the moment a wrap was added.

Peter

I once wrote an OOPS in C system (called OopsCDaisy for the fun of it.)

It was super duck typed.

Every class had every method.

If you invoke a method that wasn’t defined on that class or its ancestor,
it did nothing.

Worked quite well. None of this if variable has this method invoke method,
just invoke method and have done.

John Carter Phone : (64)(3) 358 6639
Tait Electronics Fax : (64)(3) 359 4632
PO Box 1645 Christchurch Email : john.carter@tait.co.nz
New Zealand

A Million Monkeys can inflict worse things than just Shakespeare on
your system.

···

On Mon, 15 Dec 2003, David Naseby wrote:

Duck-typing is variable scoped, not class scoped: it
answers the question “Can the current variable understand the message
#some_message?”.

Your last statement undoubtedly has merit, but keep in mind that variables are
objects in Ruby and objects are as they are for the classes that constitue
them, even if they are anonymous, which is really the key to this.

Also I think you highlight one of my points. You imply by kidnapping that
someone owns the definitive rights to the “duck” term. Furthermore,
ridiculous means laughable – and actually I hope you are laughing. It’s fun
to laugh. That’s why the word duck exists here, becuase its fun! Would you
have rather I been formally serious and said “run-time type”? You see, my
meaning was conveyed, and thus I dispute that it was “incorrect”.

By the way, I did not just mean interface inheritence. I had generalized my
inquery quite beyond that, hence my Original Question about inplace
assignment.

···

On Sunday 14 December 2003 09:51 pm, David Naseby wrote:

-----Original Message-----
From: T. Onoma [mailto:transami@runbox.com]

of Ruby is an Elitist attitude. This Duck Typing issue is a good
example of
what I’m talking about. I don’t understad why people feel it is
neccessary to
CONTROL the use of this term.

People generally CONTROL the incorrect usage of any expression. “Duck
similarity” is a ridiculous kidnapping of a term, when really you meant an
interface inheritence. Duck-typing is variable scoped, not class scoped: it
answers the question “Can the current variable understand the message
#some_message?”.


T.

OopsCDaisy? That actually sounds familiar – not to mention a very fun name.
And the idea is quite interesting too. But I’m a bit confused. Do youn mean
that every class had all the same methods as every other class?

···

On Sunday 14 December 2003 10:06 pm, John Carter wrote:

On Mon, 15 Dec 2003, David Naseby wrote:

Duck-typing is variable scoped, not class scoped: it
answers the question “Can the current variable understand the message
#some_message?”.

I once wrote an OOPS in C system (called OopsCDaisy for the fun of it.)

It was super duck typed.

Every class had every method.

If you invoke a method that wasn’t defined on that class or its ancestor,
it did nothing.

Worked quite well. None of this if variable has this method invoke method,
just invoke method and have done.


T.

You could invoke any method on any object of any class.

But what would happen thereafter depended very much on the class of
the instance.

The default behaviour was system settable, either

  • print a debug statement to the log file, or
  • Do nothing and just return.

For example, the Person object wouldn’t have a
“paint_yourself(colour)” method. Thus if you had a mixed bag of
objects, you could tell the whole bag to “paint_yourself( blue)”, the
drawable objects would paint themselves blue and the people would just
do nothing.

In practice mixed bags of objects were not all that common though, but
if duck typing is more accessible they may start to be.

It’s sort of like the default parameter on Hash.new what do you want
hash[unknown_key] to be today? What do you want
object.unknown_method() to do today?

···

On Mon, 15 Dec 2003, T. Onoma wrote:

On Sunday 14 December 2003 10:06 pm, John Carter wrote:

On Mon, 15 Dec 2003, David Naseby wrote:

Duck-typing is variable scoped, not class scoped: it
answers the question “Can the current variable understand the message
#some_message?”.

I once wrote an OOPS in C system (called OopsCDaisy for the fun of it.)

It was super duck typed.

Every class had every method.

If you invoke a method that wasn’t defined on that class or its ancestor,
it did nothing.

Worked quite well. None of this if variable has this method invoke method,
just invoke method and have done.

OopsCDaisy? That actually sounds familiar – not to mention a very fun name.
And the idea is quite interesting too. But I’m a bit confused. Do youn mean
that every class had all the same methods as every other class?


T.

John Carter Phone : (64)(3) 358 6639
Tait Electronics Fax : (64)(3) 359 4632
PO Box 1645 Christchurch Email : john.carter@tait.co.nz
New Zealand

A Million Monkeys can inflict worse things than just Shakespeare on
your system.

John Carter wrote:

You could invoke any method on any object of any class.

But what would happen thereafter depended very much on the class of
the instance.

The default behaviour was system settable, either

  • print a debug statement to the log file, or
  • Do nothing and just return.

For example, the Person object wouldn’t have a
“paint_yourself(colour)” method. Thus if you had a mixed bag of
objects, you could tell the whole bag to “paint_yourself( blue)”, the
drawable objects would paint themselves blue and the people would just
do nothing.

In practice mixed bags of objects were not all that common though, but
if duck typing is more accessible they may start to be.

It’s sort of like the default parameter on Hash.new what do you want
hash[unknown_key] to be today? What do you want
object.unknown_method() to do today?

Hmm. I’m uncertain how good this idea is in general practice.

But unless I’m missing something, it would be trivial to do this
in Ruby, simply by defining method_missing for every class.

Hal

This sounds like some “fun” code I was writing the other day, just for the
heck of it. I wrote a module I called CloseCall, and it defined
method_missing. It searches all the methods on the object with the same
(or compatible) arity, and uses the String#fuzzy_match method from the
code snippets on rubyforge to find a method with a similar name. When it
finds one similar enough, it uses class_eval to define the method, so
method_missing doesn’t get called the next time.

I can post the code if there’s any interest, but it’s not terribly pretty,
as it was more of an experiment than anything. :slight_smile:

Derek Lewis

···

On Mon, 15 Dec 2003, Hal Fulton wrote:

But unless I’m missing something, it would be trivial to do this
in Ruby, simply by defining method_missing for every class.

===================================================================
Java Web-Application Developer

  Email    : email@lewisd.com
  Cellular : 604.312.2846
  Website  : http://www.lewisd.com

“If you’ve got a 5000-line JSP page that has “all in one” support
for three input forms and four follow-up screens, all controlled
by “if” statements in scriptlets, well … please don’t show it
to me :-). Its almost dinner time, and I don’t want to lose my
appetite :-).”
- Craig R. McClanahan

As usual, Matz & Ruby is way ahead of us…

class Object
def method_missing(symbol)
end
end

class Mallard
def quack
puts “Quack!”
end
end

“SuperDuck”.quack
1.quack
nil.quack
Mallard.new.quack

all = [“SuperDuck”,-3, 4.0,nil,, {}]
all.each {|d| d.quack}

ruby -w super_duck.rb
Quack!
Quack!

Everythings a Duck! All Hail the Super Duck!

Quack! Quack! Quack!

John Carter Phone : (64)(3) 358 6639
Tait Electronics Fax : (64)(3) 359 4632
PO Box 1645 Christchurch Email : john.carter@tait.co.nz
New Zealand

A Million Monkeys can inflict worse things than just Shakespeare on
your system.

···

On Mon, 15 Dec 2003, Hal Fulton wrote:

But unless I’m missing something, it would be trivial to do this
in Ruby, simply by defining method_missing for every class.

I would certainly enjoy seeing it. How much have you tried it out?

T.

···

On Monday 15 December 2003 01:31 am, Derek Lewis wrote:

This sounds like some “fun” code I was writing the other day, just for the
heck of it. I wrote a module I called CloseCall, and it defined
method_missing. It searches all the methods on the object with the same
(or compatible) arity, and uses the String#fuzzy_match method from the
code snippets on rubyforge to find a method with a similar name. When it
finds one similar enough, it uses class_eval to define the method, so
method_missing doesn’t get called the next time.

I can post the code if there’s any interest, but it’s not terribly pretty,
as it was more of an experiment than anything. :slight_smile:

I’ve probably spent about 2 hours trying it out. There’s a flag in it for
how close a match is required (you can make something line “asdeflk” match
String#detect if you set it low enough), and it seems to work reasonable
well if that value is set to something high (in the range 0 - 1.0), like
0.5 - 0.75.

I’ve attached the source. FuzzyMatch.rb is from rubyforge.org (in the
code snippets) section, slightly modified.

CloseCall.rb (2.42 KB)

FuzzyMatch.rb (3.53 KB)

···

On Mon, 15 Dec 2003, T. Onoma wrote:

On Monday 15 December 2003 01:31 am, Derek Lewis wrote:

This sounds like some “fun” code I was writing the other day, just for the
heck of it. I wrote a module I called CloseCall, and it defined
method_missing. It searches all the methods on the object with the same
(or compatible) arity, and uses the String#fuzzy_match method from the
code snippets on rubyforge to find a method with a similar name. When it
finds one similar enough, it uses class_eval to define the method, so
method_missing doesn’t get called the next time.

I can post the code if there’s any interest, but it’s not terribly pretty,
as it was more of an experiment than anything. :slight_smile:

I would certainly enjoy seeing it. How much have you tried it out?

T.

Derek Lewis

===================================================================
Java Web-Application Developer

  Email    : email@lewisd.com
  Cellular : 604.312.2846
  Website  : http://www.lewisd.com

“If you’ve got a 5000-line JSP page that has “all in one” support
for three input forms and four follow-up screens, all controlled
by “if” statements in scriptlets, well … please don’t show it
to me :-). Its almost dinner time, and I don’t want to lose my
appetite :-).”
- Craig R. McClanahan