RE: Object spec, try 2 [x-adr][x-bayes]
On Mon, 2003-03-03 at 16:52, Garrett Goebel wrote: From: Erik Bågfors [mailto:[EMAIL PROTECTED] On Sun, 2003-03-02 at 23:21, Dan Sugalski wrote: Okay, here's another shot at the semantics for objects. If folks, especially non-perl folks, would look this over and chime in, I'd much appreciate it. Objects have (all optional): *) Properties *) Methods *) Attributes Can you give a clear example of what the difference is between properties and attributes? My imperfect understanding is: attribute is only used in an OO context and refers to the data members the class or object encapsulates. property has nothing inherently to do with OO. Properties are tags against variables and values and are compile or run time specific. Hints to the compiler and interpreter... Ok, any example of such a property? Also, how is the difference between a class variable and a object variable? Don't you mean class attribute and object attribute? The first is class-wide and accessible to all objects, whereas the latter is specific the object instance: Ofcourse... you missunderstod me (I see now that my english wasn't very good). After I sent my mail the answer jumped up in my head so just ignore this :) /Erik -- [EMAIL PROTECTED] fingerprint: A85B 95D3 D26B 296B 6C60 4F32 2C0B 693D 6E32
Re: Object spec, try 2
On Sun, 2003-03-02 at 23:21, Dan Sugalski wrote: Okay, here's another shot at the semantics for objects. If folks, especially non-perl folks, would look this over and chime in, I'd much appreciate it. Objects have (all optional): *) Properties *) Methods *) Attributes Can you give a clear example of what the difference is between properties and attributes? Also, how is the difference between a class variable and a object variable? Maybe I would have understod better if I read the last object spec better :) /Erik -- [EMAIL PROTECTED] fingerprint: A85B 95D3 D26B 296B 6C60 4F32 2C0B 693D 6E32
Re: Objects, finally (try 1)
On Thu, 2003-01-23 at 15:46, Gopal V wrote: Ruby needs to call the missing_method method (if I remember correctly). So if foo doesn't exist, it would be good to be able to override callmethods behavior and make it call missing_method. like I said , the compiler designer can put that explicitly in the generated code ... You don't actually need instructions to do that. Also the explicit generation might prove to be better to handle all the quirks future languages might encounter Sure, there is only one problem with that. I don't know if it's a real problem or not. But if I write a library in ruby that depends on the missing_method method it will not be usable from other languages, since those languages doesn't call missing_method if the method they try to call doesn't exist. Of course, in real life I don't think that's a problem because I haven't seen much use of missing_method. Also, having a instruction would be faster which of course is more fun :) My interest here is to obtain a clear and fast way to call stuff for static compiled languages. :) But the really interesting thing about parrot is that it is primarily made for very dynamic languages. Personally I think it's quite ok if C# is a little bit slower under parrot than under mono/dotgnu/MS.NET, as long as the dynamic languages are as fast or faster than they are now. /Erik -- Erik Bågfors | [EMAIL PROTECTED] Supporter of free software | GSM +46 733 279 273 fingerprint: A85B 95D3 D26B 296B 6C60 4F32 2C0B 693D 6E32
Re: Objects, finally (try 1)
On Wed, 2003-01-22 at 19:46, Christopher Armstrong wrote: On Wed, Jan 15, 2003 at 01:57:28AM -0500, Dan Sugalski wrote: At 9:37 PM -0500 1/14/03, Christopher Armstrong wrote: But who knows, maybe it could be made modular enough (i.e., more interface-oriented?) to allow the best of both worlds -- I'm far too novice wrt Parrot to figure out what it'd look like, unfortunately. It'll actually look like what we have now. If you can come up with something more abstract than: callmethod P1, foo that delegates the calling of the foo method to the method dispatch vtable entry for the object in P1, well... gimme, I want it. :) Just curious. Exactly how overridable is that `callmethod'? I don't really know anything about the vtable stuff in Parrot, but is it possible to totally delegate the lookup/calling of foo to a function that's bound somehow to P1? Or does the foo entry have to exist in the vtable already? Sorry for the naive question :-) Oh, and if you just want to point me at a source file, I guess I can try reading it :-) Python basically requires that each step in the process be overridable. (1. look up attribute 2. call attribute, at least in `callmethod's case). Ruby needs to call the missing_method method (if I remember correctly). So if foo doesn't exist, it would be good to be able to override callmethods behavior and make it call missing_method. /Erik -- Erik Bågfors | [EMAIL PROTECTED] Supporter of free software | GSM +46 733 279 273 fingerprint: A85B 95D3 D26B 296B 6C60 4F32 2C0B 693D 6E32
Re: Object semantics
On Sat, 2003-01-04 at 04:05, Dan Sugalski wrote:
At 7:27 PM +0100 1/3/03, Erik Bågfors wrote:
On Sat, 2003-01-04 at 00:28, Gopal V wrote:
If memory serves me right, Dan Sugalski wrote:
language-level we're object-oriented dammit! objects, not the
lower-level stuff we're currently working with) should/will behave.
yay ! ... finally !
The moment we've all been waiting for :)
Sheesh, everyone lay on the guilt, why don't you? :-P
Working on it
To be honest, I won't have much time from next week so now is probably
the only time I have to do something for a long time. So all I can do
is lay on the guilt :)
reference-style objects and non-reference values.
How large can a non-reference value be ? ... (in the .NET opcodes the
'struct' seems to be unlimited in size ...) But well, I'd settle for
a non-reference of at least large integers (64bit)...
And how will non-reference values dispatch methods ? ... would they be
boxed into a reference for each method call, so that the method call
can modify them ? ...or are all non-reference values immutable ?
to put it down clearly ...
MyValueType a;
a.Modify();
would a be able to modify itself ? (unfortunately C# allows that)
So does ruby. We need that :)
I wasn't aware that ruby had value types--I thought it was all
reference types. Time to crack open the nutshell book again,
apparently.
Well, An object can certainly modify itself.
: [bagfors@detrius]$ ; irb
irb(main):001:0 a=test
test
irb(main):002:0 a.sub!('e','s')
tsst
irb(main):003:0 p a
tsst
nil
But they are still reference types.
irb(main):006:0 a=test
test
irb(main):007:0 b=a
test
irb(main):008:0 a.sub!('e','s')
tsst
irb(main):009:0 p a
tsst
nil
irb(main):010:0 p b
tsst
nil
So I guess it just modifies the reference. (oh.. I really need to learn
more about low-level language-stuff...)
/Erik
--
Erik Bågfors | [EMAIL PROTECTED]
Supporter of free software | GSM +46 733 279 273
fingerprint: A85B 95D3 D26B 296B 6C60 4F32 2C0B 693D 6E32
Re: Object semantics
On Sat, 2003-01-04 at 00:28, Gopal V wrote: If memory serves me right, Dan Sugalski wrote: language-level we're object-oriented dammit! objects, not the lower-level stuff we're currently working with) should/will behave. yay ! ... finally ! The moment we've all been waiting for :) reference-style objects and non-reference values. How large can a non-reference value be ? ... (in the .NET opcodes the 'struct' seems to be unlimited in size ...) But well, I'd settle for a non-reference of at least large integers (64bit)... And how will non-reference values dispatch methods ? ... would they be boxed into a reference for each method call, so that the method call can modify them ? ...or are all non-reference values immutable ? to put it down clearly ... MyValueType a; a.Modify(); would a be able to modify itself ? (unfortunately C# allows that) So does ruby. We need that :) /Erik -- Erik Bågfors | [EMAIL PROTECTED] Supporter of free software | GSM +46 733 279 273 fingerprint: A85B 95D3 D26B 296B 6C60 4F32 2C0B 693D 6E32
Re: Ruby iterators and blocks (was: Perl 6 Summary)
On Thu, 2002-07-04 at 11:19, Andy Wardley wrote:
On Tue, Jul 02, 2002 at 03:20:35PM -0500, Dan Sugalski wrote:
I'm pretty sure the iterators they build are just closures with named
arguments, and behave as any other closure would behave.
Not quite. Ruby iterators expect a block. This is very much like a closure
except that block parameters are local to the scope in which the block is
defined, not lexically scoped within the block.
Or in other words, any existing variable of the same name as a block parameter
will be updated when the block is called.
An example:
n = 10
def twice
yield 1
yield 2
end
twice { |n| puts Hello World #{n} }
puts n is now #{n}
The result of this is:
Hello World 1
Hello World 2
n is now 2
I personally believe this approach is flawed, especially considering the fact
that there is no way (that I know of) to force block parameters to be truly
lexically scoped or temporary (i.e. 'my' or 'local' in Perlspeak). Much too
easy to mangle existing variables like this.
Most people agree. In the future there will be a way of doing that.
Matz himself has said so.
/Erik
--
Erik Bågfors | [EMAIL PROTECTED]
Supporter of free software | GSM +46 733 279 273
fingerprint: A85B 95D3 D26B 296B 6C60 4F32 2C0B 693D 6E32
