Re: [ANN] Microlight (was Re: paving cowpaths with libraries)

[Jay Carlson <nop@...>]

On Feb 20, 2012 1:56 AM, "steve donovan" <steve.j.donovan@gmail.com> wrote:
>
> On Sun, Feb 19, 2012 at 8:30 PM, Dirk Laurie <dirk.laurie@gmail.com> wrote:

> > I prefer an object-oriented approach in which sets and lists are predefined classes.
> > We've got it in the core for strings, we don't have it for tables because
> > tables are  too versatile to tie down.  No such objection for lists and sets.
>
> It is very convenient to have these classes available. Actually mlx
> has a List class which wraps table.* and the list-like ml functions.
> (And I'm still having cognitive dissonance from List vs Array)

This has problems scaling, or rather it really needs global
coordination and/or a lot of repetitive typing. I started down this
path with LOM (well, it was lxptree at the time). Because I was going
to be working with code I didn't control, I realized all of my public
functions would have to rewrap their arguments, and in that particular
case, deep-rewrap them. And hope nobody else had their own enhanced
list-like things.

Perhaps adding the wrapping is a good thing; I'm a bit more
assert-happy than most people and explicit tagging of "this table has
the dictionary nature" vs "this table has the array nature" could
catch some problems. But for those benefits, everybody has to change.
It's swimming against the existing codebase. I think it needs to go
back in mlx for a while until there's been more experience building
with it, especially in multi-module systems.

Speaking of guilt-by-naming, I was wondering if the class stuff ought
to have explicitly-ml naming, like mlclass(). Other people have sucked
up the words "object" and "class" in their systems; I think
emphasizing ml.mlclass is just *an* object system rather than *the*
object system would ease adoption. It's not like you're going to be
typing mlclass() a lot....

I was going to complain about the presence of an object system at all,
but I've come to agree that people will be looking for it, and I can't
really find much to criticize as it is in fact fairly representative
of what people do and what the language steers you towards; the only
design choice is it being class-y vs prototype-y, but the JavaScript
refugees aren't going to notice. I grew up in a prototype/delegation
system
so I'm biased.

> List.sorted() [...] List.sort()

After reading about the Qt convention of an imperative verb for
mutation vs adjectival for functional, I think I like that too.

> > Personally I have no objection to metamethods in these: L1..L2 for extend,

aaaaaaaaa

OK, of all of them I suppose that's the least objectionable. If you
ever use it in a loop you'll be really sorry though, since it can't
really mutate L1, right?

Jay