Am 16.11.2016 um 06:29 schrieb [GDS|Entropy]:

>> As of recently, an official experimental branch exists that supports
>> more advanced data containers:
> 
> Sweet! Is this in UberPov in any form yet?

Not yet.


>> For giggles, the branch also adds support for a new flavour of
>> one-dimensional integer-indexed array that can grow dynamically as needed.
> 
> Thats cool, does it have Queue type push/pop operation?

Nah, so far it just provides the bare minimum for not having to specify
a maximum size at initialization.


>> The next step would be to introduce some syntax to assign macros to
>> arbitrary (i.e. non-global) variables, ideally without actually
>> duplicating the macro; that would effectively turn the dictionary type
>> into a mechanism for object-oriented programming (using duck-typing).
> 
> That also is a great idea.
> 
> Being able to define a class or other named container laid out the same way
> (properties, constructor and such) would be nice too though but probably a
> huge pain, otherwise I would guess it would already exist, which I guess is
> why the dictionary is setup the way it is.

To be honest, there's something I like about duck-typing -- but yeah,
avoiding the hassle of implementing a type system with inheritance and
all is probably the main reason I'm going that route. A type system can
probably be bolted on later.

> Before I read your comment I was seriously considering making an SDL I/O
> macro for handling JSON, just so I could make class like structures in a
> known language, but that is not needed I guess now unless it would be very
> helpful to have.

As a matter of fact, an inbuilt JSON import feature also already exists
in the same drawer the variable-type arrays reside in (not a
coincidence; my idea is to convert the JSON data directly into a
corresponding hierarchy of SDL containers, but this requires that arrays
can hold variable types), as part of an effort to import DAZ Studio DSON
material definitions.

Post a reply to this message