Variable classes

[Xan xan]

Hi,

Is it possible to use class variables in alore. In other words, is
there any equivalent of @@variable in ruby or ClassName._variable in
python?

I need for doing counter in class instances in my alore project (a
console bug tracking system emulation of ditz)

Thanks,
Xan.

[Jukka Lehtosalo]

On Tue, May 8, 2012 at 9:59 AM, Xan xan <xanc...@gmail.com> wrote:
> Hi,
>
> Is it possible to use class variables in alore. In other words, is
> there any equivalent of @@variable in ruby or ClassName._variable in
> python?

The typical way to do this is to use a module-level variable (perhaps
prefixed with the class name). The rationale for this is that a module
is the basic unit of organizing code in Alore.

If you need a separate instance of the variable for each class in an
inheritance hierarchy, you can use a Map from a Type object to value,
for example. You can get the type of any value by using
reflect::TypeOf.

> I need for doing counter in class instances in my alore project (a
> console bug tracking system emulation of ditz)

Sounds cool!

Jukka

[xancorreu]

Al 08/05/12 22:36, En/na Jukka Lehtosalo ha escrit:

> On Tue, May 8, 2012 at 9:59 AM, Xan xan<xanc...@gmail.com> wrote:
>> Hi,
>>
>> Is it possible to use class variables in alore. In other words, is
>> there any equivalent of @@variable in ruby or ClassName._variable in
>> python?
> The typical way to do this is to use a module-level variable (perhaps
> prefixed with the class name). The rationale for this is that a module
> is the basic unit of organizing code in Alore.
>
> If you need a separate instance of the variable for each class in an
> inheritance hierarchy, you can use a Map from a Type object to value,
> for example. You can get the type of any value by using
> reflect::TypeOf.

Mmm... I want a variable in the class, not in the module.

In python I have this:

[...]
class Task:
|____numtasks = 0

|___def __init__(self):
|___|___self.tags = []
|___|___Task._numtasks = Task._numtasks + 1
|___|___self.num = Task._numtasks
[...]

I want to port this code to alore. But putting 'numtasks' in module is
ugly, I think.

>> I need for doing counter in class instances in my alore project (a
>> console bug tracking system emulation of ditz)
> Sounds cool!
>
> Jukka

Thanks,
Xan.

[xancorreu]

Al 09/05/12 10:08, En/na Jukka Lehtosalo ha escrit:

> Here's how you could do it in Alore. I don't think that it's any
> uglier, but YMMV. However, I'm planning to add class methods and
> variables in the future.
>
> var NumTasks = 0
>
> class Task
> var tags, num
> def create()
> self.tags = []
> NumTasks = NumTasks + 1
> self.num = NumTasks
> end
> end
>
> Jukka
Yes, it's what I was thinking... well, variable classes could be
emulated by module varibles. You're right. Overall the class is const.
Perpaps a locals of Actors could serve you as inspiration for future
releases: http://fantom.org/doc/docLang/Actors.html

I could put module and NumTasks private (reachable only in the module)?




By the other hand, really, your previous idea is good: define a Map<Str,
Int> of number of instances of each class. This works:

var instances = Map<Str, Int>()
instances["Task"] = 0

and self.num = instances["Task"]


Thanks,
Xan.

[xancorreu]

>
> By the other hand, really, your previous idea is good: define a
> Map<Str, Int> of number of instances of each class. This works:
>
> var instances = Map<Str, Int>()
> instances["Task"] = 0

It does not work with Map<Str,Int> but yes with Map alone. Why? The
alonec does not send any error. The compiled script yes.

[Xan xan]

2012/5/10 Jukka Lehtosalo <jleht...@gmail.com>

On Wed, May 9, 2012 at 1:52 PM, xancorreu <xanc...@gmail.com> wrote:
> Al 09/05/12 10:08, En/na Jukka Lehtosalo ha escrit:
>

...
[how to use class variables in Alore]
...

>> Here's how you could do it in Alore. I don't think that it's any
>> uglier, but YMMV. However, I'm planning to add class methods and
>> variables in the future.
>>
>> var NumTasks = 0
>>
>> class Task
>>   var tags, num
>>   def create()
>>     self.tags = []
>>     NumTasks = NumTasks + 1
>>     self.num = NumTasks
>>   end
>> end
>>
>> Jukka
>
> Yes, it's what I was thinking... well, variable classes could be emulated by
> module varibles. You're right. Overall the class is const. Perpaps a locals
> of Actors could serve you as inspiration for future releases:
> http://fantom.org/doc/docLang/Actors.html

Thanks for the pointer. Actors are probably better than plain threads
for most programs, but it's still not obvious what's the best way of
implementing them in Alore. Threads are simply too error-prone and
difficult to test/debug, especially in larger projects with multiple
programmers and a lot of (potentially) shared state.

You're welcome.
Another way of doing concurrency is pipes, like Go does. It has the benefits that we could do concurrency without classes, just main function and pipes, and actors require classes and not always you want classes....

I think that the Actors could be implemented as a library on top of pipes. With this approach, you have user comfortable syntax and core-without-class (means more generally) code written in pipes....

Do you think about concurrency model in Alore? This is a critical feature. There are few too many langs with this feature. A good concurrency language could have a star language ;-)
 

> I could put module and NumTasks private (reachable only in the module)?

Yes, just prefix with private:

private var NumTasks = 0

Thanks.
 

> By the other hand, really, your previous idea is good: define a Map<Str,
> Int> of number of instances of each class. This works:
>
> var instances = Map<Str, Int>()
> instances["Task"] = 0
>
> and self.num = instances["Task"]
>

What about that? Why this code does not work and var instances = Map() does?

Thanks,
Xan.

>
> Thanks,
> Xan.

Jukka

[xancorreu]

Al 10/05/12 12:06, En/na Jukka Lehtosalo ha escrit:
> On Thu, May 10, 2012 at 10:20 AM, Xan xan<xanc...@gmail.com> wrote:
>>
>> 2012/5/10 Jukka Lehtosalo<jleht...@gmail.com>
> ...

>>> Thanks for the pointer. Actors are probably better than plain threads
>>> for most programs, but it's still not obvious what's the best way of
>>> implementing them in Alore. Threads are simply too error-prone and
>>> difficult to test/debug, especially in larger projects with multiple
>>> programmers and a lot of (potentially) shared state.
>>
>> You're welcome.
>> Another way of doing concurrency is pipes, like Go does. It has the benefits
>> that we could do concurrency without classes, just main function and pipes,
>> and actors require classes and not always you want classes....
>>
>> I think that the Actors could be implemented as a library on top of pipes.
>> With this approach, you have user comfortable syntax and core-without-class
>> (means more generally) code written in pipes....

> Yep, it would be useful to have pipes/message queues as a low-level
> interface. There could be multiple higher-level actor class libraries
> built on top of the low-level interface to choose from.

>
>> Do you think about concurrency model in Alore? This is a critical feature.
>> There are few too many langs with this feature. A good concurrency language
>> could have a star language ;-)

> I've been thinking about this quite a lot, and I think an actor-style
> programming model + low-level interface based on message passing
> between threads with isolated heaps might work well. Some applications
> might need data structures shared across actors/threads, though, but
> shared-nothing (data) would be a good default.


Yes. We coincide on this. I have a pain not contributing to the code,
because I just a mere user. I don't have technical skills to program a
decent concurrent library for alore. I'm sorry.

>>>> By the other hand, really, your previous idea is good: define a Map<Str,
>>>> Int> of number of instances of each class. This works:
>>>>
>>>> var instances = Map<Str, Int>()
>>>> instances["Task"] = 0
>>>>
>>>> and self.num = instances["Task"]
>>>>
>>
>> What about that? Why this code does not work and var instances = Map() does?

> Ah, missed this one. You can do it like this:
>
> var instances = Map() as<Str, Int>
>
> You need the "as<...>" since otherwise the syntax would be ambiguous
> (it could be parsed as (Map< Str), (Int> ()) ).
>
> Jukka
Ah!, thanks.

Xan.