[Isomorphic]

For the other 190, how can the generator tell if they are supposed to inherit from Class or if they are just missing a legit inheritsFrom attribute?

Because we are adding the inheritsFrom attributes (and a few in that list already have it by the way, it must be stale).

There are 8 objects with inheritFrom attributes:

Yes, objects with inheritsFrom attributes inherit from whatever is declared. Others do not.

[kylemwhite]

I've really been trying to grasp why we have differing opionions on the inheritsFrom attribute and here's what I've concluded. I've had a different model in my head than what Isomorphic does. For items marked with type="class":

My (working) definition of the inheritsFrom attribute

A class inherits from whatever is in the inheritsFrom attribute which ultimately inherits from Class. If there is no inheritsFrom attribute, then it must be the base Class (or a mistake).

The (presumed) Isomorphic definition:

All classes inherit directly from Class (except the base Class) unless the inheritsFrom attribute specifies otherwise, in which case it inherits from the inheritsFrom class which ultimately inherits from Class.

I can see now why (using the Isomorphic definition), marking classes with inheritsFrom="Class" would seem redundant. Since they're marked with type="class", it is implied that they inherit from Class already.

These definitions are really close. However, I prefer my definition (all classes have an inheritsFrom attribute unless it is the base class) because it makes it easier for code generators to know what to do. If a class is missing an inheritsFrom attribute, it is very easy to discover and thus fix. And, if it seems redundant, who cares? It doesn't make the file significantly bigger but it DOES make things clearer, more robust and easier to find mistakes via automation. A bit of redundancy is a small price to pay for that.

With the (presumed) Isomorphic definition, if a class is missing the inheritsFrom attribute, there's no way to know if that was on purpose because it inherits directly from Class or if it is a mistake (without looking outside of the referenceDocs.xml file).

I can see no downside to using my definition, I doubt that it would break the exisitng SmartGWT or Docs code generators because nothing will change in the framework itself and they would (probably) generate the proper 'extends' based on the attribute instead of inferring it from the lack of the attribute. I'm just proposing a modification to the referenceDocs.xml file (by including an inheritsFrom attribte in ALL classes except Class) to make is easier for all code generation and make it more error-proof. This definition is also consistent with objects because:

Yes, objects with inheritsFrom attributes inherit from whatever is declared. Others do not.

(i.e. there is no implied inheritsFrom)

Please consider. Thanks.

Also, neither of our definitions work for the isc class as it does not inherit from Class at all. It seems to me that it should be marked as type="object" (and it is actually referred to as 'The isc object' in the docs).

[kylemwhite]

@jaredm: Thanks for the encouragement. Please have a look at the repository https://github.com/kylemwhite/isc and provide feedback. If there are particular classes, objects or methods you need that are missing, let me know and I'll include them in the next release (if they generate properly).

[kylemwhite]

Because we are adding the inheritsFrom attributes (and a few in that list already have it by the way, it must be stale).

I've been regenerating every day from this URL: http://www.smartclient.com/smartclie...erenceDocs.xml and I haven't seen any additional inheritsFrom attributes. Am I using the correct file?

[Isomorphic]

In Java when you define a new Class you do not have to declare that you inheritFrom Object. Same thing with SmartClient, except our implicit base class is called "Class". So we don't want to go add dozens of redundant definitions throughout our codebase, just as someone writing in Java would not want to add them. And if were just automatically added to all classes that lacked it, that would have the same effect as if the script just assumed it, so no point.

That file is up to date, yes, and we've checked that it does have additional inheritsFrom, such as an Layout. So your list appears stale.

[kylemwhite]

Layout is not on the list. Do you have another example of one (or several) that has been recently added?

[Isomorphic]

Layout is on the list in your post #45. So perhaps for that particular post you just copied from a stale list.

[kylemwhite]

OMG. Post #45 is soooo yesterday. Yes that list could have been old. The current list is updated daily in the repository here: https://github.com/kylemwhite/isc/bl...ter/Errors.txt. I've got everything automated to download the latest file at 7am (CA time) and generate the latest files. When I get into the office, I can check them out, compile and if everything is good, commit to the repository.

I've just now adjusted the generator to create the Errors.txt file BEFORE applying fixes and the count of missing inheritsFrom is up to 202. I know that most of these really implicitly inherit from Class but there are still many that do not (VLayout, HLayout etc.) and I don't have an automated way of distinguishing between the two cases. Suggestions are welcome.

[kylemwhite]

I've adjusted the generator to create properties as readonly if there is no W flag. This is working and the TypeScript compiler won't let me assign to a readonly property, great. But, I now have an error in my program on this line:

grid.filterButtonPrompt = "Clear the filter"   // grid is a ListGrid

The filterButtonPrompt property is now readonly (because it is not marked with the W flag) and there is no setFilterButtonPrompt() method. So, is the filterButtonPropmpt property just not supposed to be updateable or is it missing the W flag?

The code works in JavaScript and in TypeScript if I do:

(grid as any).filterButtonPrompt = "Clear the filter"   // grid is a ListGrid

So I suspect it's just missing the W flag. And, if that's the case, can you think of a way that the code generator could help find these errors?

[Isomorphic]

filterButtonPrompt is indeed not writable after create(). It looks like it happens to work in some case you've found, but that's just luck, not a supported feature.

But unfortunately, your code would still be wrong even if it were a writable property. See documentation for the IRW flags we referred you to earlier: if a property is writable after create(), you need to either call it's setter or call setProperty().

[kylemwhite]

Understood. I am currently modifying the generator with these rules. Please verify that they make sense.

• If an attribute is not marked with the W flag, make it readonly.
• If an attribute has a getter and a setter, then don't generate the property at all (i.e. force use of getter and setter).
• If an attribute is readonly (no W flag), and has a getter, then hide it (i.e force use of the getter).
• If an attribute is writeable (has a W flag) and has a setter but no getter, then make it readonly (i.e. create the property for reading but enforce use of the setter for writing).

[kylemwhite]

Oops, after re-reading about the flags, I think the rules are even simpler:

• ALL properties are readonly because if the attribute is writeable, you must use the setter or setProperty().
• If an attribute has a getter then don't generate the property at all (i.e. force use of getter).

[Isomorphic]

By "properties" here we think you specifically mean accessing and assigning via dot notation (object.someProperty) without a method call. If so, then your second set of rules is correct.

[kylemwhite]

Yes, I'm trying to use the term 'attibute' to refer to the attributes on SC classes/object and properties to refer to JS/TS dot notation properties and method for functions including setters and getters. I think we're on the same page.

[kylemwhite]

I've run into a snag. On the Tab object, there are many attributes marked with the W flag and no setters. Since Tab is an object, it does not inherit from Class which means that it has no setProperty() method either. So, if the attribute is writable, doesn't have a setter and it belongs to an object that does not inherit from Class, what is the correct way to set the value?