Implementing tables - advice wanted
Tue Jun 13 14:24:59 CEST 2006
I have programmed in Smalltalk for about 15 years and find the
collection types key to every app. Dictionary is very important.
However, these are all mutable objects.
1 - If the idea to have a table syntax is to introduce mutable
collections, I would say it would quickly lead to a breakdown of the
single assignment nature of erlang programs.
2 - If the the idea is simply to have a syntax for constructing
immutable tables, this could be nice. But any "real" app will have
large enough or unpredictable "structure" in these tables meaning
that almost all programs will access the table "object" via an API,
not a syntax where the names of fields are hard coded. Your syntax
does look nice and could prove useful for teaching erlang, but the
core API would be used more for larger apps.
3 - I don't see much value in this new data type if the key must be
only atoms or strings. Too restrictive and would only server special
cases. I am used to using hash table where the key may be a domain
object. Unless of course, you can create a non-mutable, highly
performant, space conscious hash table to replace most uses of record.
4 - Is the performance/space characteristics of module dictionary
It is common practice (smalltalk, java, python, ruby) in model and
controller frameworks to store attributes as hash tables keyed by
attribute name. This representation is very handy for abstract
framework code to manipulate attributes, handle events, etc...
However, the code should always encapsulate the internal
implementation. This means the app programmer never sees the
dictionary/hash table. So syntactic sugar for creating/accessing the
tables isn't exposed to the app programmer. Smalltalk and Java have
several good dictionary types but do not have special syntax for
them. This works out just fine.
What I really need is the ability to pass around records (treat them
as objects: meaning I have the discipline not to access them directly
but via some module which owns its representation) and reference the
fields by name via some record module's API. So, why would I need
to have a record's fields be available outside its created module if
I'm disciplined enough to always use said module to access the
record? Well, for creating abstract frameworks and helper "objects",
of course. I need to write some reusable "abstract" modules that are
closely coupled to their "concrete" counterpart. This abstract code
needs to know things about the record. I am doing just that in some
erlang framework code I'm working on, but I feel its a bit clumsy and
may not be efficient. I would think just one or two well performing
APIs for record field would be just what I need.
I also need a good template engine for yaws ;-)
just my 2 cents, ke han
On Jun 13, 2006, at 6:30 PM, Richard Carlsson wrote:
> Joe Armstrong (AL/EAB) wrote:
>> Erlang really really really (^100) needs tables.
> Allow me to disagree somewhat. Erlang already has good tables,
> both using hashing (dict) and binary trees (gb_trees). The
> syntactic convenience of a built-in table/dictionary type is
> really a minor thing. (Not that I would oppose having such a
> notation, but I really don't think it is critical in any way.)
> The main advantage would be psychological, I think: a standard
> one-size-fits-all dictionary type makes it easier for people to
> start using them in public interfaces, and not just internally.
> What I _do_ miss now and then (and when I need them, I have to
> jump through several hoops to get them) is indexable tables
> (i.e., arrays) with O(1) access time and a _small_ constant
> factor, and no copying of the stored data.
> If I remember correctly, the experiment with a "vector" data
> type (which used destructive update internally, with some
> penalty for accessing older versions of the data) was killed
> by bad interaction with the garbage collector, leading to
> rotten performance. Have things changed enough in the GC by
> now for this to become worth a new attempt?
More information about the erlang-questions