"Io [http//www.iolanguage.com] uses actors and transparent futures for concurrency. An actor can be thought of as an object oriented thread. ... When an object receives an asynchronous message it puts the message in its queue and, if it doesn't already have one, starts a light weight thread (a coroutine) to process the messages in its queue. Queued messages are processed sequentially in a first-in-first-out order. Control can be yielded to other coroutines by calling 'yield'."
> I'm taking a little poll.
>
> Let say you're Matz, but without any of the pressures of keeping up with
> a previous version of Ruby. What one thing above all others would you
> like to see differ about Ruby?
I would be happy to see class variables (@@var) disappear. But I
don't like the idea of class_attr_reader and things like that. Just
use the existing attr_* methods, which Class objects already have just
as much access to as other objects. If a Class object needs its own
state, let it keep its own state. If it wants other objects to have
access to it, let it give them access.
But @@vars cut upwardly across the class hierarchy, which is a bit different.
Is that right? Please correct me if I'm wrong.
Hand-in-hand with this, and for other reasons, I would like my
Kernel#singleton_class RCR to be accepted I think that would make
the whole singleton-class model enormously easier to explain and
grasp. Unfortunately it's still surrounded by a kind of mystique and
mystery for many people -- which is really too bad, since it's
actually so simple and transparent and cool.
Ruby Facets offer all of these BTW:
require 'facet/class/cattr'
gives you #cattr_reader, #cattr_writer and #cattr_accessor. And
require 'facet/object/special_class'
provides #singleton_class (alias of #special_class).
T.
···
On Sunday 16 January 2005 07:35 am, David A. Black wrote:
On Sunday 16 January 2005 04:21 am, Csaba Henk wrote:
On 2005-01-16, trans. (T. Onoma) <transami@runbox.com> wrote:
> I'm taking a little poll.
>
> Let say you're Matz, but without any of the pressures of keeping up with
> a previous version of Ruby. What one thing above all others would you
> like to see differ about Ruby?
Quoteing csaba@phony_for_avoiding_spam.org, on Sun, Jan 16, 2005 at 06:21:08PM +0900:
···
On 2005-01-16, trans. (T. Onoma) <transami@runbox.com> wrote:
> I'm taking a little poll.
>
> Let say you're Matz, but without any of the pressures of keeping up with a
> previous version of Ruby. What one thing above all others would you like to
> see differ about Ruby?
Docstrings.
Let's see what Matz (the real one) says about this (in ruby-talk:20264):
"" Yes, indeed. Docstring is for man (or woman), so that - I think -
"" interpreter itself does not need to have them. Lisp (including Emacs)
"" and Smalltalk have interactive environment built in. Docstrings is
"" useful in such systems. Ruby is not. For example, in daemon program
"" written in Ruby, docstrings are nothing but memory burden.
But, for heaven's sake, I use ruby as an interactive environment quite
reguralry! In fact, it's a beautiful interactive environment (except for
irb can be extended to support ri, why isn't this better than
docstrings?
On Jan 15, 2005, at 7:23 PM, trans. (T. Onoma) wrote:
I'm taking a little poll.
Let say you're Matz, but without any of the pressures of keeping up with a
previous version of Ruby. What one thing above all others would you like to
see differ about Ruby?
Two very different things: a truly cross-platform GUI and IO's concurrency.
talking about Io and crossp'latform.. a student from robert feldt made a thesis about a ruby+opengl gui toolkit inspired from Io's one and Squeak's one. It would be a long way behind wx or tk, anyway
Have a different threading approach, maybe Agent-like.
I'm very comfortable using the POSIX multi-threading model, but one or more higher level MT models would also be nice, especially when it comes to getting less experienced people into threaded design. To me, Pthreads are like the assembly language level of MT programming.
I think as long as you start with a solid POSIX API, any higher level threading model, e.g. agents, or Linda's tuple-space, can be provided. OS-based threads just make it work better.
Base the IO system on asynchronous event driven stuff such as libevent. I also found funny that in ruby-land people often wants OS threads and in python-land were they have them people often wants asynchronous stuff (i.e. twisted)
Yes, threads are asynchronous so they go well with an asynchronous i/o event model.
I have used Ruby threading quite a bit and I must say I have _no_ desire for this feature.
In fact I hate the very notion.
Perhaps if I had a multi-CPU machine and hyperthreading I might care a bit more.
Maybe.
I doubt it.
The trouble is C threading just has so many ways it which it can go wrong it really frightens me.
Ruby would simply loose it's rock solid stability if they did OS level multi-threading.
Almost always threading is a fast and filthy fix on something that can be done better as multiprocesses. It is a kludge resulting from early MS-Windows not having a fast implementation of "fork()"
I would _much_ rather any efforts on concurrency on making multi-
process IPC slick.
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
"The notes I handle no better than many pianists. But the pauses
between the notes -
ah, that is where the art resides!' - Artur Schnabel
···
On Sun, 16 Jan 2005, Glenn Parker wrote:
trans. (T. Onoma) wrote:
I'm taking a little poll.
Let say you're Matz, but without any of the pressures of keeping up with a previous version of Ruby. What one thing above all others would you like to see differ about Ruby?
yeah. if my mod would be anything, it would be a mod
that allows matz to create unlimited amounts of money
and pass some of it on to the many people working there
asses off on making ruby faster
Alex
···
On Jan 16, 2005, at 5:26 AM, Ryan Davis wrote:
No more C code! Love ruby. Don't love ruby internals. I would like ruby to be written in ruby. That would be something I could love.
P.S. I'm working on this already. Email me for details.
underscores in most languages indicate 'things thou shall not touch'
in ruby otoh, @vars are simply not accessible from outside, therefore,
i'd prefer @. i find _ annoys my eyes not to mention my fingers @data -> data at self
otoh makes perfect sense.
Alex
···
On Jan 17, 2005, at 5:06 PM, Daniel Berger wrote:
I vote for using a leading underscore instead of "@" sign for instance
variables. Perhaps a leading double underscore for "@@" (class
variables).
trans. (T. Onoma) wrote:
> I'm taking a little poll.
>
> Let say you're Matz, but without any of the pressures of keeping up
with a
> previous version of Ruby. What one thing above all others would you
like to
> see differ about Ruby?
>
> T.
I vote for using a leading underscore instead of "@" sign for
instance
variables. Perhaps a leading double underscore for "@@" (class
variables).
Oh, I also forgot to add that I would like 'require' to check its
current directory first, so I can stop doing "$:.unshift Dir.pwd".
Regards,
Let say you're Matz, but without any of the pressures of keeping up with a previous version of Ruby. What one thing above all others would you like to see differ about Ruby?
C-core lazy generators (or Icon's 'suspend', though I'm not sure how
well that will play with the rest of ruby).
aren't this a kind of coroutine? Can't you build them with callcc easily?
In message "Re: Fwd: [suby-ruby] Your all time desired fundemental Ruby mod" on Tue, 18 Jan 2005 01:06:06 +0900, "Daniel Berger" <djberg96@hotmail.com> writes:
I vote for using a leading underscore instead of "@" sign for instance
variables. Perhaps a leading double underscore for "@@" (class
variables).
class Foo
__var = 23
def initialize
_x = 1
end
end
Double underscores are reserved for "private" instance variables that
cannot be seen from subclasses. Don't take this as a promise for the
feature.
I second the optional runtime type checks. That is the only feature I'd like to see.
-Jeff
···
----- Original Message ----- From: "Curt Sampson" <cjs@cynic.net>
To: "ruby-talk ML" <ruby-talk@ruby-lang.org>
Sent: Monday, January 24, 2005 1:16 AM
Subject: Re: Fwd: [suby-ruby] Your all time desired fundemental Ruby mod
1. Consistent, concise syntax, with one simple way to do things.
2. Type inference.
3. A move to a more purely functional approach in the libraries (i.e.,
String.gsub stays, but String.gsub! goes.)
cjs
--
Curt Sampson <cjs@cynic.net> +81 90 7737 2974 http://www.NetBSD.org
Make up enjoying your city life...produced by BIC CAMERA
> Hi --
>
> > I'm taking a little poll.
> >
> > Let say you're Matz, but without any of the pressures of keeping up with
> > a previous version of Ruby. What one thing above all others would you
> > like to see differ about Ruby?
>
> I would be happy to see class variables (@@var) disappear. But I
> don't like the idea of class_attr_reader and things like that. Just
> use the existing attr_* methods, which Class objects already have just
> as much access to as other objects. If a Class object needs its own
> state, let it keep its own state. If it wants other objects to have
> access to it, let it give them access.
But @@vars cut upwardly across the class hierarchy, which is a bit different.
Is that right? Please correct me if I'm wrong.
You're right -- I meant to clarify that I'm talking about 2.0 class
vars, which as I understand it will be truly per-class and will differ
from instance variables of Class objects principally in that they will
be in scope in instance methods. I would rather not have a separate
construct that overlaps so much with instance variables.
As for the current way class variables work... I'm not convinced that
would be a big loss either. I've seen class variables arise as a
source of confusion over and over again -- and while I don't mind
there being things that have to be explained and that take a bit of
study to grasp, the weight of experience suggests to me that there's
room for refinement in this area. My chosen method of refinement
would be to eliminate them
David
···
On Sun, 16 Jan 2005, trans. (T. Onoma) wrote:
On Sunday 16 January 2005 07:35 am, David A. Black wrote:
> On Sun, 16 Jan 2005, trans. (T. Onoma) wrote:
--
Jim Menard, jimm@io.com, http://www.io.com/~jimm/
"Master, does Emacs have the Buddha nature?" the novice asked.
"I don't see why not. It's got bloody well everything else."
-- John Fouhy
I think ultimately that's the way to go, but I'm more inclined to bind to
ParaGUI. But one way or another I will be headed down this road. If anyone's
interested please contact me.
T.
···
On Sunday 16 January 2005 09:46 am, gabriele renzi wrote:
Jim Menard ha scritto:
> On Jan 15, 2005, at 7:23 PM, trans. (T. Onoma) wrote:
>> I'm taking a little poll.
>>
>> Let say you're Matz, but without any of the pressures of keeping up
>> with a
>> previous version of Ruby. What one thing above all others would you
>> like to
>> see differ about Ruby?
>
> Two very different things: a truly cross-platform GUI and IO's
> concurrency.
talking about Io and crossp'latform.. a student from robert feldt made a
thesis about a ruby+opengl gui toolkit inspired from Io's one and
Squeak's one. It would be a long way behind wx or tk, anyway
I think that would make