This thread has covered the main points effectively already, so I'll just
tack on some thoughts to the side.
Since it seems that your frustration fundamentally comes down to how
components are implemented in 4D, a couple of other ideas:
1) Give up on components in 4D.
2) If you're using components, consider a "tell, don't ask" approach.
(Miyako nodded towards this concept in recent weeks.) In this case, it
would mean storing the data in the component and telling the component what
to do. In other words, don't keep pulling stuff out of the component and
back into the host for manipulation - do the manipulation in the component.
This doesn't make a whole lot of sense much of the time in 4D, but there
are places where it does. At the least, it's an interesting design
perspective to consider...even if it isn't what you find to be the best fit
in some specific situation.
Okay, a couple of other thoughts:
* I think that what 4D did to use JSON for complex data types is kind of a
great idea. Bravo. But let's not think for a minute that these are
"Objects" in any interesting or meaningful sense of the word. *Nothing* has
been added to the language or compiler to assist with custom types, we
don't have closures ("lamda functions"), there's no object levels of scope,
and no object methods. So, they're structured text with benefits, that's it.
NTK's JSON is still a nice alternative since it's a full JSON
implementation. (Nice for getting JSON in and out of 4D, not just passing
data within 4D.) With NTK, you can pass around a longint reference to the
container very efficiently.
I did a bit of work with PHP a bit back and it gave me a new perspective on
a couple of things. First off, I was using it mainly for Mustache, which
gave me a new appreciation for logic-less templating. It's worth thinking
about before diving into 4DCODE, for example.
But more to the point, I really enjoyed the PHP style of jamming text
together and then explode()ing it into arrays for manipulation. It's very
convenient. Lately, I've found this creeping into my 4D style quite a bit.
Let's say you've got a bunch of content to manipulate and you want to pass
it around. Well, you can pass a bunch of arrays, a BLOB, an object, or a
block of text. Since 'objects' in 4D are nothing but chunks of structured
text, do I always need to hassle and overhead of JSON? No I do not.
Instead, I use TSV (Tab Separated Values) - another kind of structured text
with other benefits. Some benefits:
* Ideal for columnar data that doesn't contain unescapable tabs or carriage
returns as content.
* Small: JSON always adds data with all of that syntactic sugar.
* Easy: So, so easy to work with. Parsing on a CR is a snap and then
parsing lines in a loop on tabs, also a snap. Maybe you want arrays, maybe
you want JSON, maybe you want to do some calculations...it's all easy
enough.
* Flexible: I end up with routines that want some data from a larger
object. Say the host source has 8 values per row. Some routines want 8,
some want 5, and some want 3. And then another one wants a different 3.
Pass in a description of what's needed from the extract routine and get
back your custom collection of 'column'. Either way, $0 is still a block of
text. The calling routine knows what it ask for, so it knows how to parse
it out. The main extract routine only needs to know what to include, not
what to do with it after the fact. A very neat division of responsibilities.
Some disadvantages:
* JSON is prettier, likely to be more self-documenting, and all of the cool
kids use it. I'm actually totally fanatical about JSON, it's the
interchange format we've always needed. So great. Doesn't mean it's the
best fit for every problem.
* JSON is *great* for hierarchical data. It's just a natural fit.
* Larger text blocks are easier to store and see in JSON...they're hard in
flat text files...maybe that's just me.
So, I use JSON and I use TSV, but I find they've each got their uses.
A nod of the head to D3 as well here, it's all about JavaScript....but is
more than happy to read in CSV, TSV, etc. and auto-convert to a JS array of
objects. Why? Because TSV, etc. are a lot more compact wire formats than
JSON and That Is Good.
Right, back to your regular discussion
**********************************************************************
4D Internet Users Group (4D iNUG)
FAQ: http://lists.4d.com/faqnug.html
Archive: http://lists.4d.com/archives.html
Options: http://lists.4d.com/mailman/options/4d_tech
Unsub: mailto:[email protected]
**********************************************************************
