#105107 - 2003-09-26 02:21 PM
Re: kixforms versions, wtf
|
Shawn
Administrator
Registered: 1999-08-13
Posts: 8611
|
roflmao, you sheephurter you. No, I am struggling with something on Kixforms right now. The damn Namespace issue is driving me insane. Its important and I want (have) to work it out now as opposed to later.
Its not a technical issue, its a usability/optics issue to do with the overall "layout" of how objects are instantiated in Kixforms vs dotnet.
In dotnet, there are dozens and dozens of different namespaces, some usefull and some totally useless (as far as Kixtart and scripting are concerned). For example, in dotnet, to create assign a Font object to a font property one specifies this:
Form.Font = System.Drawing.Font("Verdana",12)
and to start a process:
Proc = System.Diagnostics.Process.Start("Notepad.exe")
well, I have gone and implemented some of these namespaces (ie, Drawing) but I am finding that the code is getting very long-winded and overly complicated, for example:
$Form.Font = $Forms.Drawing.Font("Verdana",12,$Forms.Drawing.FontStyles.Normal)
What I have been playing with lately, is a simplified version of the namespaces, with every object (all of them) availble from the root namespace. This tends to make things easier to understand and (importantly) remember:
$Form.Font = $Forms.Font("Verdana",10,$Forms.FontStyles.Normal)
$Object = $Forms.Object()
$Process = $Forms.Process.Start("Notepad.exe")
$File = $Forms.File.Open("x.tmp")
so bascially, all the dotnet objects from the various namespaces (drawing, diagnostics, IO) would be made available throught the root namespace called $Forms (Kixtart.Forms)
Anyway, like I said, still doing much coding to determines which "style" I like better.
|
|
Top
|
|
|
|
|
#105112 - 2003-09-26 05:22 PM
Re: kixforms versions, wtf
|
Shawn
Administrator
Registered: 1999-08-13
Posts: 8611
|
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 ]
|
|
Top
|
|
|
|
|
#105113 - 2003-09-26 07:49 PM
Re: kixforms versions, wtf
|
Shawn
Administrator
Registered: 1999-08-13
Posts: 8611
|
hmmm, aweful quiet out there ![[Wink]](images/icons/wink.gif) but I have noticed one thing, whenever I talk about or think about code examples for namespaces, I always want to use the fully qualified namespace. Wonder if I should listen to that sub-conscience tendency ?
|
|
Top
|
|
|
|
|
#105115 - 2003-09-26 07:55 PM
Re: kixforms versions, wtf
|
Howard Bullock
KiX Supporter
Registered: 2000-09-15
Posts: 5809
Loc: Harrisburg, PA USA
|
Shawn, taking an example from Perl...
When a script includes additional non-core functionality the methods and properties can be accessed via fully qualified names because they actually exist in separate namespaces.
In the module the author can call an EXPORTER function that loads the method names, properties, etc into the MAIN namespace.
Could you provide something similiar? That way you can have both ways or halfway for that matter.
|
|
Top
|
|
|
|
|
#105116 - 2003-09-26 08:18 PM
Re: kixforms versions, wtf
|
Shawn
Administrator
Registered: 1999-08-13
Posts: 8611
|
hmmm, an exporter function, in a way that can be done with build 42 now, the root namespace ($forms) is expando so actually, the developer can assemble his own namespace at startup, kinda like:
code:
$Forms = CreateObject("Kixtart.Forms")
$Forms.Drawing = CreateObject("Kixtart.Drawing")
$Forms.Diagnostics = CreateObject("Kixtart.Diagnostics")
$Forms.JLO = CreateObject("Kixtart.Bastah")
or the alternate that was already discussed before at KFO was just shortcut all the namespaces, example:
code:
$Forms = CreateObject("Kixtart.Forms")
$Drawing = CreateObject("Kixtart.Drawing")
$Diagnostics = CreateObject("Kixtart.Diagnostics")
$JLO = CreateObject("Kixtart.Bastah")
We had kinda already settled on this strategy but the thing is, I am always finding that I forget to include the namespace shortcuts at the top of the script, there is alread one that is absolutely required ($Forms) and thought that having the namespaces already avaliable through the root, or by just having all the objects consolidated into the root, would be easier to code and (importantly) to document.
|
|
Top
|
|
|
|
|
#105117 - 2003-09-26 08:36 PM
Re: kixforms versions, wtf
|
Howard Bullock
KiX Supporter
Registered: 2000-09-15
Posts: 5809
Loc: Harrisburg, PA USA
|
Combining assumes that you do not have any duplicate names in different namespaces that actually have different values/purposes which would clash if combined.
|
|
Top
|
|
|
|
|
#105118 - 2003-09-26 08:44 PM
Re: kixforms versions, wtf
|
Howard Bullock
KiX Supporter
Registered: 2000-09-15
Posts: 5809
Loc: Harrisburg, PA USA
|
Although I like shorter object and property names, I think that the shortcut objects you list above are not intuitive.
Something like is more to my liking if possible.
code:
$Forms = CreateObject("Kixtart.Forms")
$Forms.include("Kixtart.Drawing")
$Forms.include("Kixtart.Diagnostics")
$Forms.include("Kixtart.Bastah")
[ 26. September 2003, 20:45: Message edited by: Howard Bullock ]
|
|
Top
|
|
|
|
|
#105119 - 2003-09-26 09:54 PM
Re: kixforms versions, wtf
|
Shawn
Administrator
Registered: 1999-08-13
Posts: 8611
|
Well tbh, I am trying to shy away from having to create or include extra namespaces at all. I want to make Kixforms more like the Office or Internet Explorer COM objects, were one just simply "includes" a global namespace reference like:
code:
$Excel = CreateObject("Excel.Application")
$IE = CreateObject("InternetExplorer.Application")
and then ALL the objects are derived out-of the single namespace. I find this approach (imho) much more intuitive then the DOTNET approach of having a bazillion includable namespaces. I guess the problem is, I am try marry the single namespace approach with the multiple one used by dotnet.
But getting back to your idea, assume there was an object with a namespace path like this:
code:
Kixtart.Drawing.Font
and then one did this:
code:
$Forms.Include("Kixtart.Drawing")
Would the object be then referenced directly out of the root, like this (because it was "included"):
$Forms.Font
or would include the namespace into the root just extend the root with a new property called Drawing, and the object would still be referencd like this:
$Form.Drawing.Font
|
|
Top
|
|
|
|
|
#105120 - 2003-09-26 10:33 PM
Re: kixforms versions, wtf
|
Shawn
Administrator
Registered: 1999-08-13
Posts: 8611
|
Actually Hoby, you got me to thinking, your statement:
quote:
Combining assumes that you do not have any duplicate names in different namespaces that actually have different values/purposes which would clash if combined.
is very, very important. To the best of my knowledge, there would be no namespace clashes. But the organization of objects into namespaces certainly does avoid this problem problem though. hmmm ... crap.
|
|
Top
|
|
|
|
|
#105121 - 2003-09-26 10:51 PM
Re: kixforms versions, wtf
|
Howard Bullock
KiX Supporter
Registered: 2000-09-15
Posts: 5809
Loc: Harrisburg, PA USA
|
My include example was intended to show that ALL methods & properties would be addressable from the root $Form.whatever.
A nice thing might be selective including.
code:
$Forms = CreateObject("Kixtart.Forms")
$Forms.include("Kixtart.Drawing").export(list of items to make addressable in ROOT namespace)
or some such thingie.
[ 26. September 2003, 22:52: Message edited by: Howard Bullock ]
|
|
Top
|
|
|
|
Moderator: Arend_, Allen, Jochen, Radimus, Glenn Barnas, ShaneEP, Ruud van Velsen, Mart
|
1 registered
(Allen)
and 641 anonymous users online.
|
|
|
![[Frown]](images/icons/frown.gif){kind=icon}
![[Big Grin]](images/icons/grin.gif){kind=icon}
