[erlang-questions] next(Erlang): "Fix up records so that records are first-class citizens and not just syntax saccharine for tuples?"

[Steve Davis]

On Nov 21, 6:15 am, "damien morton" <dmor...@REDACTED> wrote:
> On Fri, Nov 21, 2008 at 10:16 PM, Steve Davis
>
> <steven.charles.da...@REDACTED> wrote:
> > If you are really serious about this - here are some considerations/
> > dogma from me:
> > - Don't try to support inheritance (preferring decorators will save
> > you untold issues later)
>
> Heh. I dont think anyone is proposing that.
>

Thank goodness! (Good call).

> > - Consider how close/far JSON maps to record tuples
>
> Richard's frames map very nicely to JSON and back.
>

Hmm. JSON uses Strings for property names -- is it really an impedance
mismatch that you should dismiss so easily?
i.e.
JSON: { "Object": {"name": "Damien", "location": "here" }}
Erlang: -record(object {name, location}) which has a tuple
representation { "Damien", "here" }
(case differences emphasized for effect)

> > - C.J. Date once said that the big issue with ORM was SQL's lack of
> > support for relational domains
>
> You're talking about enum equivalents?

I'm saying that objects should be representable in long-term storage
without a high impedance mismatch, and should not be an afterthought.
Pick a strategy now. (Erlang's strategy was tuple storage...

As for enums, if you wonder why atoms are so powerful, then take a
detailed look at Java's respresentation/implementation/use sometime.
It's a picture of a struggle against its own rules.


>
> > - XML is a disaster for almost all purposes, so don't be tempted to
> > use it for "configuration" or "communications" (it took me a while to
> > finally understand Joe's view, but I am 110% there now)
>
> Do you have a link to Joe's view on XML?
>
Ulf gave the best link. XML (invented at Microsoft) is SGML for
idiots, (HTML is SGML for complete idiots which is why it became so
popular). Where XML went wrong is that everybody forgot that XML
stands for extensible MARKUP language. i.e. the intention is to
provide easy to read HINTS for DOCUMENT DISPLAY. Things like schema,
relax-ng, and functional additions like xpath etc are bolt on's to
improve the semantics of your hints, but mean that XML is not for
idiots any more. That being so, and evaluated as it should be now as a
data definition/transformation hybrid language, it's simply
repetitive, unnecessarily hard to parse, transfer and simply bloats
the codebase. It's so noisy that it's no longer easy to read or write
which makes the whole machine-readable thing moot. Given only a
developer can write it now, why not use some kind of universal binary
format that's fast to transmit, easy to parse and saves both
electricity, trees, and developer time -- oh wait... didn't Joe
suggest that? :) IN THIS CONTEXT (yes there's a point) *reconsider*
the relationship between json, tuples, and record/object
representations.


> > - The entire set of required modifiers is likely: required, unique,
> > optional, readonly (and possibly "hidden")
>
> > - The entire set of required fundamental types is likely: text,
> > number, flag
> > - Don't allow nulls in any shape or form
>
> Ahh - the "schema" I referred to was merely the set of keys - its just
> an implementation detail that the set of keys _can_ be shared between
> frame instances, though this is not necessary. Probably the wrong word
> to use.

Actually my point was that you probably need constraints that make
sense to long-term store and thin clients to make any object
implementation truly useful and robust. Not everything is an object,
but then not everything is a function either (even if one can be used
to represent the other i.e. in OOP functions are second-class, in
lambda - data structures are second class. There's definitely room for
an equal partnership if you can devise one :)

/s