[Vimperator] un[let]

[Doug Kearns]

On 9/19/07, Виктор Кожухаров <vkojouharov at gmail.com> wrote:
> В ср, 2007-09-19 в 03:37 +1000, Doug Kearns написа:

<snip>

> My idea is to also have JS be the main language,
> and if we isolate such useful functions, script writes can use them with
> ease (lets say that all JS/vimscript scripts are executed so that the
> main namespace is not window, but vimperator.vimscript).

Yes but I think Martin had a good reason that it was inconvenient to
do that now, however,  I can't quite remember what that was at the
moment.

<snip>

> > Looks useful to me. Two quick comments:
> > - Options have a value property so you don't need to call getter() explicitly
> I was looking for something like that, but the only thing I could find
> was getter(). So .value would be equivalent to .getter() then?

Yes.

> > - variableReference() should probably be a 'private' helper...at least for now.
> unless I'm mistaken here, this would mean that variableReference would
> only be accessible from methods of the vimperator object. However, this
> is also used for the commands, so I don't see how to make it private.

Right, but with your current implementation wouldn't you really just
use v.globalVariables.x?

I'm not sure what utility there is in passing "g:x" to
variableReference and it returning [v.globalVariables, "x", "g"] -
particularly if there's not much chance of the other variable scopes
appearing anytime soon.

Just one more style issue to annoy you... I'm probably outnumbered
here but I really don't think there's any point in these arg guard
clauses we use - they really just hide bugs.  I'd much prefer for it
to simply fail when called without an arg (or passed an empty string)
than return a result that would probably lead the caller to simply
conclude that the variable was undefined. Client code has _some_
responsibilities. ;-)

<snip>

Regards,
Doug