Accesing structures data (getting lengthy!)

Scott Seidman wrote:
> Christopher Hulbert <cchgroupmail@xxxxxxxxx> wrote in
> news:67165BB72D9E93C9E408412DDB7E3B8C@xxxxxxxxxxxxxxxxxxx:
>
>
>>I don't want to start the argument up again, but I still don't see how
>>a "with" keyword is so much better. According to the syntax you
>>posted earlier, you have to type the leading . anyways, is a leading
>>w. really that much more inconvient or ugly?
>
>
> It's not really an argument. I happen to have a task at hand that would
> profit from this construct. (1) is the way I used to do things, and it
> didn't really work for me. Now, I float the deep structure to the top,
> and it works a tad better for me. I have an easier time prototyping and
> coding, and in my situation it's easier, but its really a kludge, and
> suffers from some of the same problems that your syntax (1) does, which
> I'll describe below. If the "with" construct existed, I would use that,
> and I wouldn't feel bad about it, like I do when floating a deep
> structure to the top.
>
> I also know that sometimes I go out of my way to avoid using structures
> with names and organizations that make perfect sense, simply because I
> don't want to have to type the whole damn thing every time I want to use
> anything in them for any reason.
>
>
>>Consider two syntaxes (1) a matlab way (2) the "with" keyword way
>>
>>(1)
>>w=my.very.nested.structure;
>>
>>w.this
>>w.that
>>w.whatever
>>
>>w=my.very.nested.structure2;
>>w.this
>>w.that
>>w.whatever
>>
>>(2)
>>with my.very.nested.structure;
>>
>>.this
>>.that
>>.whatever
>>
>>with my.very.nested.structure2;
>>.this
>>.that
>>.whatever
>>
>>Are they really that different????
>>
>>
>
>
> I think I can convince you that they are, if you'll excuse my late-
> afternoon verbosity.
>
> They're different from the readability point of view. In (1), you've
> created a temporary variable that has no meaningful name (assuming that
> if its more than a few characters, there's a level of tediousness). My
> prototyping work from the command line is hard enough to make sense of
> more than two minutes after I've typed it right now--I don't need to add
> to it by creating a fruit salad of placeholders and dummy variables.
> When you're working from the keyboard in a prototyping sort of way, it's
> tough to remember just what you were using 'w' for (or maybe I was using
> 'a' as my meaningless place holder??....). It's tough to go back through
> your history (or your editing enviroment) to pick up "w=" as the
> assignment statement just won't stand out amongst all the other
> assignment statements.
>
> (2), however, is quite readable. It doesn't create a fruit salad of
> meaningless dummy variables that you have to keep track of. "with" is
> comparitively easy to pick out of a long, boring, command line history,
> and would certainly be highlighted in any IDE-type editor worth its salt.
> When you click on or mouse over a structure that starts with a period,
> the editor can highlight the currently active "with" line, or pop it up
> as a "tip". Maybe from the command line, simply typing "with" with no
> arguments would provide the currently active stucture.
>
> They're clearly very different from a memory point of view, with (1)
> taking up, worst case, twice the memory with respect to the arrays of
> interest (certainly if you change all the arrays, copies would be
> created). While the other points can be considered mere preferences, I
> don't think you can argue with this one.
>
> The biggest and most annoying aspect of using (1) is that you are acting
> on a mere copy of the object you want to act on. When you act on an
> object using (2), you're using the real deal. When using (1), you have
> to remember to go back and fix up your original structure. I'm sure I
> can find extremely creative ways to have this one bite me on the ass--
> ways that are hard to debug. Putting the placeholder back into the
> original, for some reason, wraps me up in knots. Think about this:
>
> tryme.a.a1=1
> tryme.a.a2=2
> tryme.a.a3=3
> w=tryme.a
> w.a1=5
> tryme.a=w %<=====This seems somehow nasty!!!!
> tryme.a
>
> Acting in the forward direction, from 'tryme' to 'w' is pretty natural,
> but going in the backward direction, for some reason, doesn't seem
> natural to me at all, and for some reason, I have to think about it every
> time I do it. It seems really easy to screw up your whole structure just
> by leaving out the last "a", and that seems like something I would do all
> too often (like typing "clear" instead of "close", a habit which I've
> managed to break without even overloading clear!), especially when
> structures run particularly deep. Sometimes, I even feel the need create
> yet another extra copy of the original structure, in case I mess it up in
> this tricky step.
>
> In fact, now that I'm thinking about it, using method (1), it's
> ABSOLUTELY CRITICAL to do all your work in w, and then bring it back to
> tryme.a. If you accidentally do anything to tryme.a, you will lose all
> your changes when you copy w to tryme.a!!! Using construct (2), this
> situation never arises. This is a hard one to argue away, as well. (1)
> and (2) are looking more and more different! Note that this wouldn't be
> a problem if there were a way to ALIAS or EQUIV w to tryme.a, or we had
> some sort of #define preprocessor, but those don't exist. You could also
> bring w to tryme.a in a loop, element by element, and not lose any
> additions you've made to tryme.a, but you would still lose modifications
> of anything that existed when w was created. Also, if we had to restore
> tryme.a with a nasty loop, alot of the appeal of (1) goes away.
>
> Your argument against the "with" statement seemed to be centered around
> the idea that syntax (1) made it fairly unnecessary. So, now that I've
> pointed out some problems inherent to using syntax (1), we should go back
> and look at problems with syntax (2).
>
> The whole "with" concept seems relatively straightforward to implement,
> and shouldn't interfere with the parser too much. It would create errors
> that might be harder to trace if people accidentally put a space in their
> structure names before a period, but that creates an error already. It's
> not like the zero-referenced array request that a bunch of serious signal
> processors militantly demanded, as it wouldn't touch built in functions,
> or any other functionality, for that matter it shouldn't effect any old
> code, so long as there are no variables called "with". There might even
> be exciting unforseen benefits--seems like it would be doable to create
> separate namespaces in the base, for example.
>
> In a function, I see no real problems. However, from the command line,
> constructs like (2) usually get evaluated after the "end" statement is
> typed, but "with" really wouldn't be able to work this way-- There may be
> some problems associated with a "sticky with" at the command line (but
> nowhere near the potential problems and misunderstandings caused by using
> "cell" with two completely different meanings). Searching for the
> construct usage, and having to parse out variable names that start with a
> period, might add unacceptable loads to the parser, and might somehow
> mess up the grammar. I can't speak to implementation by the good folks
> at Mathworks--that really isn't my bag--but there might be implementation
> problems that make the whole deal unworkable.
>

You raise good issues. I guess i've never used a language (that I can
think of) that has the with keyword (or its equivelant), so I have never
used it. Nor have I run into the problem of needing it. So dismissing
its usefulness would be like dismissing the usefulness of every function
i've not used. Alas, if it solves the problems of some, I say why not!
.

Relevant Pages

  • Re: Accesing structures data (getting lengthy!)
    ... According to the syntax you ... assignment statement just won't stand out amongst all the other ... meaningless dummy variables that you have to keep track of. ... comparitively easy to pick out of a long, boring, command line history, ...
    (comp.soft-sys.matlab)
  • Re: My Weekly Drash - Vayera
    ... you're asking what reason there might be for a ... >> literally speaking in one voice) and concluding that the law had never ... I have problem with that understanding, ... Because when the command _to him_ is to do ...
    (soc.culture.jewish.moderated)
  • Re: My Weekly Drash - Vayera
    ... >>> while I said I prefer to know the purpose of a law. ... > a reason. ... >> impart a reson to G-d's command. ... Moshe Schorr ...
    (soc.culture.jewish.moderated)
  • Re: 8.0 rc.d scripts less verbose?
    ... bug, but it's a bug that we've come to depend on. ... This late in the release cycle I'm comfortable adding a knob, ... pre-command routine or the command itself failed. ... whatever reason), it is nice to have an approximate idea which one ...
    (freebsd-stable)
  • Re: Godel Contradiction
    ... Since my ONLY reason for undertaing the arduous task of learning ... of my time if I were to discover that Godel was in fact wrong, ... that I regard the sentences: ... meaningless, I'm willing to concede the possibility that I may be ...
    (sci.logic)