On 2006-07-25, at 16:12 EDT, Philip Romanik wrote:
> Hi Tucker,
>
> I've compiled a list of questions for you. I've finished the files
> in the data directory (except for the Traits files). Hopefully this
> list will avoid two rounds of reviews.
>
> 1. In LzDataset.lzs and other places is this definition,
>
> prototype.nodeType = LzDataNode.DOCUMENT_NODE;
>
> nodeType is defined in both derived trait classes. Can this be just
> 'nodeType = ...'
If nodeType is a var declaration in one of the superclasses or traits
a class inherits from, then you can give it a different value in your
class by simply assigning to it. (I don't think C++ lets you do this.)
> 2. In LzDataset.lzs I made anonDatasourceNum a static. Can you
> verify that this is ok?
Correct.
> 3. In LzDataset.lzs is LzHttpDatasetPool. I haven't converted it
> because it looks like a singleton, and I can't find a reference to it.
Hm. I guess there may be more of these than I thought. Rethinking,
perhaps we should not worry about their singleton status so much and
at least convert them to classes. (We need them to be in class
format for the JS2 back-end.) If you have questions on how to do
that, let me know. I think you should just do something like:
class __LzHttpDataSetPoolClass { ... }
var LzHttpDataSetPool = new __LzHttpDataSetPoolClass;
> 4. In LzDatapointer.lzs is this,
> defaultattrs = {};
> Is it ok to reset the values set in LzNode?
Hm. Seems odd to me, but apparently it works. I will send a
question to Adam.
> 5. In LzDataText.lzs I had to specify the class derives from
> Instance, because lzpix doesn't start properly if I don't.
>
> class LzDataText extends LzDataNode, Instance {
Please file a bug. It is supposed to work that you can leave out the
superclass if it is Instance. Put a comment above your code:
// FIXME: [2006-07-25 pbr] (LPP-NNNN) When this bug is fixed, we can
leave out `, Instance`
> 6. In LzDataText.lzs, is this line necessary?
>
> prototype.setAttribute = LzNode.prototype.setAttribute;
Looks like cruft to me. I'd delete it.
> 7. Like (4), in LzDataText.lzs is,
> setters = {};
> Is this ok?
Note the comment above it. In this case, you are not inheriting from
LzNode, so you are not clobbering anything. In this case you will
have to use a `var` declaration as there is nothing to override.
> 8. In LzReplicationManager.lzs, I specified a function as static.
> Is this ok?
>
> static function __LZemptyFuntion ( ){
Yes.
> 9. Should I convert LzParsedPath.lzs? One of the functions, trim,
> is used by other files. If I make it a class, do I make this
> static, and call it via, 'LzParsedPath.trim', instead of the
> current 'LzParsedPath.prototype.trim'?
That sounds right. Hm. You'd probably like to be able to refer to
it in methods of LzParsedPath itself without a qualifier, but that
won't work just yet... Guess you should file a bug and add a comment
as in 5.
_______________________________________________
Laszlo-dev mailing list
[email protected]
http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
