Jens, one of the reasons I would like to go with a flat object model is to keep the CHM hierarchy flat, I dont necessarily want to have one tree, with props,methods,events and enums for every namespace. This is what the MSDN docs do, but would be nice for our purposes, to have a simple flat object model.

But like I said, I trying to balance features and flexibility and ease of use - and to be honest, its killing me. This is one of the reasons build 42 is so delayed.

I personally prefer the full-out namespace specification, but since Kixtart really doesn't really support namespaces (like dotnet does), the implementation is tough ... especially when it comes to enumerations (which are in build 42) - enumerations are supposed to be easy ways of specifying (remembering) property settings. But with the extended common namespace, some of the enums are long winded, example:

code:
$Form.Font = $Forms.Drawing.Font("Verdana",10,$Forms.Drawing.FontStyles.Normal)
This code actually works in Build 42, but right now I am just weighting this "syntax" with the simplified form of:

code:
$Form.Font = $Forms.Font("Verdana",10,$Forms.FontStyles.Normal)
so all objects and all enums would be available from the a single, global namespace. If you guys think that the former syntax (the dotnet compat. syntax) is not too long-winded, then let me know.

Chris,

The Object object is a template, user-defined object that is available in Build 42 (Jens already has build 42). It allows one to create a user-definable object with custom properties, for example - if you wanted to create a "User" object, one could code this:

code:
$User = $Forms.Object()
 
$User.Name = "Chris"
$User.Address = "kixtart.org"
$User.Phone = "905-KIX-TART"
$User.Foo = "Bar"
The properties are created on the fly (expando) and this object can be used just like any other COM object, for example:

code:
If $User.Name = "Chris"
 ? $User.Address
 ? $User.Phone
EndIf
The other new feature in 42 is Expando containers (form, groupbox, tabcontrol, tabpage) so now one can created custom container properties hosting just about anything you want.

code:
$Form = $Forms.Form()
 
$Form.MyButton = $Form.Controls.ToolButton()
$Form.MyButton.Text = "Click Me"
$Form.MyButton.BackColor = $Forms.Drawing.Color.Red
This feature has important "object-oriented" impacts. Instances of objects (ie, a $Form) can now be expanded to support custom properties that can contain other objects. Even if that object is a custom object. For example, a form can host properites representing it's embedded controls (buttons, listviews) or even a custom object representing the user details that the form is displaying) for example:

code:
$Form = $Form.Forms()
 
$Form.User = $Forms.Object()
 
$Form.User.Name = "Shawn"
$Form.user.Address = "kixtart.org"
The benefits here are in the encapsulation of objects into a heirarchy that is defined by you and the task at hand. Expando properties behave exactly like regular class instance variables that you get when you derive a new class from an existing class, then extend the object model. But since COM doesn't support this feature directly, its a great alternative.

The downside right now is that I can think of NOW WAY to implement custom FUNCTIONS in expando objects ... this would require an enhancement to Kixtart to support an extended Automation interface, some other languages (JS anyways) does support expando functions.

Anyways, I have rambled but would love to talk about this namespace thingy more ...

[ 26. September 2003, 17:58: Message edited by: Shawn ]