Hello,
I have the following design features in mind for wxCL library. Any
criticism/suggestions are extremely welcome.
[1] There will be only one package named "wxcl" and all the functions(about
2000) and constants (about 3000) will be exported from it.
[2]All the constants will have a leading and trailing '+' sign with
them. Example, wxcl:+default-size+. The constants will be defined using
'defconstant'.
[3]The wxcl class hierarchy will very closely mirror wxwidgets class
hierarchy.
[4] All wxcl classes will derive from the abstract class 'object' (wxWidgets
has a similar class called wxObject). The object class contains only one slot.
(defclass object ()
((obj :reader object-pointer)))
This slot will hold the pointer to the foreign object of the corresponding
class.
[5]To create objects of any wxcl class, user should call the make-<class-name>
constructor. For example
(wxcl:make-frame ....... )
will return an object of the frame class.
[6]The user of the library should not need to know anything about ffi.
[7]The different classes in wxcl should be organized in the proper inheritance
hierarchy. So, for example the 'show' method specializes on objects of class
'window', and all the widget classes inherits from the class 'window'. Hence, the
method 'show' should work on all the widget classes also.
(setf fr (wxcl:make-frame ....... ))
(show fr)
this should work because class frame inherits the window class.
[8]The getter methods in wxWidgets will have their 'get' prefix stripped off in
wxcl. For example, wxWidgets function 'getSize' will be just 'size' in wxcl,
and it will return an object of the size class.
For most of the setter methods the writer method is specialized, so setSize
can be called as
(setf (size fr) (make-size :width 500 :height 600))
[9]wxWidget setter functions which sets a particular item in a list, for
example
wxControlWithItems::SetClientObject
void SetClientObject(int n, wxClientData *data)
the equivalent wxcl function will be called as
(let ((lb (make-list-box ....))
(cl (make-client-object.....)))
(setf (client-object lb 3) cl))
[10]There maybe some functions which are exception to the above rule.
[11]The optional arguments in wxWidgets will be provided as keyword
arguments.
[12]The classes 'size' and 'position' defined in wxCL should provide same
functionality as corresponding classes in wxWidgets but they are entirely
implemented in lisp.
[13]The wxWidgets predicates which return bool will map to a similar predicate
in wxcl, except they will have a '-p' suffix, and they will return t or nil.
[14]All classes and preferably functions too should have a documentation string
describing them.
A preliminary implementation of this is available in the wxcl cvs. Any help is
extremely welcome.
Thanks a lot.
--
Surendra Singhi
http://www.public.asu.edu/~sksinghi/index.html
,----
| By all means marry; if you get a good wife, you'll be happy. If you
| get a bad one, you'll become a philosopher.
| -- Socrates
`----
>
> [5]To create objects of any wxcl class, user should call the make-<class-name>
> constructor. For example
>
> (wxcl:make-frame ....... )
>
> will return an object of the frame class.
>
Why not make-instance directly?
Or at least have a factory method to abstract all this out, so that I
can do, say:
(wxcl:make-wx-instance 'frame)
So there is less to remember, and it is similar to clos make-instance.
And in case we plan to have sexp base GUI designer: it could look like.
(frame (:title "Frame" :width 100 :size 100)
(button (:text "Click mew")))
And you could recursively make-wx-instance of each of the nodes.
Hello Pisin,
"Pisin Bootvong" <··········@gmail.com> writes:
>>
>> [5]To create objects of any wxcl class, user should call the make-<class-name>
>> constructor. For example
>>
>> (wxcl:make-frame ....... )
>>
>> will return an object of the frame class.
>>
>
> Why not make-instance directly?
> Or at least have a factory method to abstract all this out, so that I
> can do, say:
>
> (wxcl:make-wx-instance 'frame)
>
> So there is less to remember, and it is similar to clos make-instance.
Good question. There are two ways of creating widgets in wxWidgets, one is
call an empty constructor and then call the 'Create' function and set the
required parameters. The other one is to call the constructor with the
parameters.
So, I thought instead of user calling make-instance and then the create
function, there should be a one step way of creating the widget. Besides, in
Keene's book [1] it is recommended that one should define constructor
functions to be used by the client to make instances. The advantages of having
constructor is that it provides more abstract external interface and it can
have required arguments.
> And in case we plan to have sexp base GUI designer: it could look like.
>
> (frame (:title "Frame" :width 100 :size 100)
> (button (:text "Click mew")))
>
> And you could recursively make-wx-instance of each of the nodes.
I like the idea of having sexp based GUI designer, but I think even without
a factory function a macro can be written which will do it, anyway the macro will
need to know more than the class of the object, for example, if the frame has
menus, toolbar, statusbar, they all have to be handled differently.
Thank you for your suggestions, they are useful.
--
Surendra Singhi
http://www.public.asu.edu/~sksinghi/index.html
[1]Object-Oriented Programming in Common Lisp by
Sonya E. Keene, 1989 Addison-Wesley Publishing Company.
Surendra Singhi <·········@netscape.net> writes:
> Hello Pisin,
>
> "Pisin Bootvong" <··········@gmail.com> writes:
>
> >>
> >> [5]To create objects of any wxcl class, user should call the make-<class-name>
> >> constructor. For example
> >>
> >> (wxcl:make-frame ....... )
> >>
> >> will return an object of the frame class.
> >>
> >
> > Why not make-instance directly?
> > Or at least have a factory method to abstract all this out, so that I
> > can do, say:
> >
> > (wxcl:make-wx-instance 'frame)
> >
> > So there is less to remember, and it is similar to clos make-instance.
>
> Good question. There are two ways of creating widgets in wxWidgets, one is
> call an empty constructor and then call the 'Create' function and set the
> required parameters. The other one is to call the constructor with the
> parameters.
>
> So, I thought instead of user calling make-instance and then the create
> function, there should be a one step way of creating the widget.
You can do that with an after method on initialize-instance. This is
what LTK does, for example.
> Besides, in
> Keene's book [1] it is recommended that one should define constructor
> functions to be used by the client to make instances. The advantages of having
> constructor is that it provides more abstract external interface and it can
> have required arguments.
I think this is horrible advice on Keene's part. Lisp has first-class
class objects. By using a named constructor instead of using the
built-in construction facilities that come with CLOS, you lose most of
the advantage of that, and effectively prevent users from being able
to usefully subclass your classes. If that's your intent, then that's
fine, but unless you're trying to restrict what a user can do with a
certain class, do your construction with methods on initialize-instance.
--
/|_ .-----------------------.
,' .\ / | Free Mumia Abu-Jamal! |
,--' _,' | Abolish the racist |
/ / | death penalty! |
( -. | `-----------------------'
| ) |
(`-. '--.)
`. )----'
From: Joe Marshall
Subject: Re: wxCL library design - please flame it
Date:
Message-ID: <r7axgwle.fsf@alum.mit.edu>
> Surendra Singhi <·········@netscape.net> writes:
>
>> Besides, in Keene's book [1] it is recommended that one should
>> define constructor functions to be used by the client to make
>> instances. The advantages of having constructor is that it provides
>> more abstract external interface and it can have required
>> arguments.
···@conquest.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
> I think this is horrible advice on Keene's part. Lisp has first-class
> class objects. By using a named constructor instead of using the
> built-in construction facilities that come with CLOS, you lose most of
> the advantage of that, and effectively prevent users from being able
> to usefully subclass your classes. If that's your intent, then that's
> fine, but unless you're trying to restrict what a user can do with a
> certain class, do your construction with methods on initialize-instance.
I agree. make-instance and shared-initialize are designed so that
they may be extended with methods that ensure your objects are
correctly constructed. If you have a different constructor then you
are placing an extra burden on the user to remember to call that one
instead of the `normal' one. And like as not, if you forget and call
make-instance directly, the returned object will be *mostly* correct
(modulo the fixups in your external constructor) which will lead to
really obscure errors.
On the other hand, if you specialize make-instance and
shared-initialize, it is virtually impossible for a user to screw up
the instantiation.
Surendra Singhi <·········@netscape.net> writes:
> [1] There will be only one package named "wxcl" and all the functions(about
> 2000) and constants (about 3000) will be exported from it.
All seems nice, but I would have at least an additionnal nickname: "WX".
With so many exported symbols (ie. probably a lot of collision), you'd
rather always write them fully qualified.
--
__Pascal Bourguignon__ http://www.informatimago.com/
Litter box not here.
You must have moved it again.
I'll poop in the sink.
On Thu, 06 Oct 2005 14:49:22 -0700, Surendra Singhi <·········@netscape.net> wrote:
>Hello,
>
> I have the following design features in mind for wxCL library. Any
>criticism/suggestions are extremely welcome.
>
> [1] There will be only one package named "wxcl" and all the functions(about
> 2000) and constants (about 3000) will be exported from it.
>
> [snip snip]
>
Hi, Surendra. As you probably know, the wxWidgets build can be configured
to produce separate DLL's representing subsystems instead of a monolithic
DLL.
Would it make sense to define packages at these subsystem boundaries?
This would be sort of a compromise between the "all symbols in one
package" approach vs. the "one package per class" approach that is
more or less (I know this isn't completely accurate) how wxCL is
structured now.
At the same time, is it realistic to assume a reduction in CL image size
by offering separate ASDF files, so that when one builds an image the amount
of "stuff" getting pulled in can be trimmed somewhat?
One last question...would it make sense to include a version identifier
in the wxCL package(s) that maps back to the underlying wxWidgets version?
Perhaps just at the major.minor release granularity (e.g., 2.4 vs. 2.6)
just to help make it obvious that there are API differences between
wxWidgets versions.
I hope these are useful questions. :-) Keep up the good work!
--
Jack
Hello Jack,
Jack Unrue <·······@example.tld> writes:
> On Thu, 06 Oct 2005 14:49:22 -0700, Surendra Singhi <·········@netscape.net> wrote:
>
>> I have the following design features in mind for wxCL library. Any
>>criticism/suggestions are extremely welcome.
>>
>> [1] There will be only one package named "wxcl" and all the functions(about
>> 2000) and constants (about 3000) will be exported from it.
>>
>> [snip snip]
>
> Hi, Surendra. As you probably know, the wxWidgets build can be configured
> to produce separate DLL's representing subsystems instead of a monolithic
> DLL.
>
> Would it make sense to define packages at these subsystem boundaries?
> This would be sort of a compromise between the "all symbols in one
> package" approach vs. the "one package per class" approach that is
> more or less (I know this isn't completely accurate) how wxCL is
> structured now.
Yes, indeed it is a very good idea. I will look into it, and try to form a
hierarchy of what should go where.
>
> At the same time, is it realistic to assume a reduction in CL image size
> by offering separate ASDF files, so that when one builds an image the amount
> of "stuff" getting pulled in can be trimmed somewhat?
>
Maybe wxCL can provide separate asdf files for the different packages(as will
be created above). If one wants more finer granularity then I think the
user/programmer has to do it himself. Any other alternatives?
> One last question...would it make sense to include a version identifier
> in the wxCL package(s) that maps back to the underlying wxWidgets version?
> Perhaps just at the major.minor release granularity (e.g., 2.4 vs. 2.6)
> just to help make it obvious that there are API differences between
> wxWidgets versions.
Yes, will do this and I will also add a version identifier for wxCL itself.
>
> I hope these are useful questions. :-) Keep up the good work!
Thanks, they were really helpful.
--
Surendra Singhi
http://www.public.asu.edu/~sksinghi/index.html
The best-laid plans of mice and men go oft astray.
Surendra Singhi <·········@netscape.net> writes:
> Hello Jack,
>
> Jack Unrue <·······@example.tld> writes:
>>
>> At the same time, is it realistic to assume a reduction in CL image size
>> by offering separate ASDF files, so that when one builds an image the amount
>> of "stuff" getting pulled in can be trimmed somewhat?
>>
> Maybe wxCL can provide separate asdf files for the different packages(as will
> be created above). If one wants more finer granularity then I think the
> user/programmer has to do it himself. Any other alternatives?
>
What about also having something like the following:
(push :wxcl-use-button *features*)
and then using #+ or #-.
Is it a good or bad idea?
Thanks.
--
Surendra Singhi
http://www.public.asu.edu/~sksinghi/index.html
,----
| WHY SHOULD WE SAVE TIGER?
| Ans: Saving the tiger means saving mankind..
|
| Help http://pudang.tripod.com/
| or https://secure.worldwildlife.org/forms/tiger_appeal_1.cfm
`----
On Fri, 07 Oct 2005 13:21:49 -0700, Surendra Singhi <·········@netscape.net> wrote:
> Surendra Singhi <·········@netscape.net> writes:
>
> > Maybe wxCL can provide separate asdf files for the different packages(as will
> > be created above). If one wants more finer granularity then I think the
> > user/programmer has to do it himself. Any other alternatives?
> >
> What about also having something like the following:
>
> (push :wxcl-use-button *features*)
>
> and then using #+ or #-.
>
> Is it a good or bad idea?
>
> Thanks.
Personally, I think that if you do this, the features ought to be defined
at the same (or higher?) granularity level as the packages that are defined
so the two go hand-in-hand. I realize that you were just offering an arbitrary
example above, but I suspect I would be annoyed by code that had to test for
features at the level of individual widget types.
But I wonder if this is really needed anyway? I think I would want to control
the build configuration at the wxWidgets level, so I would know (as the app
developer) what features are available and write my code accordingly. Or are
you anticipating that a wxCL developer would hook up to an existing
wxWidgets install on the user's system?
How do other 'wrapper' libraries in Lisp approach this?
--
Jack