Re: [MacPerl] Porting an Inside Mac QuickDraw example routine

[ilir topalli <ilir@gis.net>]

> > All this toolbox stuff is so low level that it starts to feel like C (blech).
>
> I don't see how to change it to be more "Perl-like."  What suggestions do
> you have?
>
>



Sorry I wasn't very clear.  The functions are clearly Perl functions.  It's just that most things in Perl give you a
relatively high level way of doing things, and is usually very forgiving.  For instance the print function has a lot of
niceties that are not available in other languages, and makes basic assumptions about what the user wants that can be
overridden.  For instance it assumes you are going to print to the standard output window if you don't specify and will
even create it for you, it handles carriage returns, knows the font height , knows when to wrap to the next line and
where etc.  It's a very friendly language and I beleive that's what attracts a lot of people.  Compare this to
DrawString().

Of course one of the criticisms of perl is the same point; that there are too many was of doing things and that the
language is so forgiving that some peoples' code is unreadable.  We all know of course that these people live in the
land of ignorance  :).

The way the toolbox routines are implemented are exactly the way they should be, as they adhere to Apples strict
guidelines.  It's just that so much thought and control must be put into doing it this way that it sort of detracts from
what makes perl attractive to start: the ability to whip out code that does what you want without swetting the small
stuff.

> Do you mean just providing higher-level functions to hide some of the
>   details?  Well, yes, that does not mean changing anything about the
>   existing code, it just means writing new modules to sit on top of the
>   existing ones, like I did with Mac::AppleEvents::Simple, and I agree (if
>   that is what you mean) that there is certainly room for such modules, and
>   there even are some other modules to make such things simpler (though I
>   wish there were more, hint hint).
>
This _is_ what I meant.  AppleEvents::simple is one such thing.  As I said before the implementation of the Toolbox
routine is correct and necessary to be in that format (although it would be nice if the documentation were complete for
everything . and incedentally everything I learned, I learned with MPPE.  It is an excellent source, it's just that a
complete treatise on the toolbox may be beyond it's scope)

Higher level modules and functions  that layed on top of the Toolbox Routines would be great.



> perhaps it would even make some of the routines more portable to other
> >platforms.
>
> I don't understand this ... it cannot be portable to other platforms,
> because it depends on the Mac OS API (only available on Mac OS), and
> changing the style would not change this.  Even if it were portable,
> changing the style would not change this fact.
>
I just mean that it stands to reason that if higher level functions hide the details of the implementation,  these
higher level functions could be implemented on other platforms.  Implementing the Toolbox routines would be impossible.

Many operating systems use windows, mice, buttons, radiobuttons etc.  Even HTML does so and even, to some extent.,  Unix
do so.  Thus a command like "DrawWindow(handle,type,coordinates,sizeetc..)" or
"MakeControl(controlhandle,windowhandle,type,location,subroutine etc)" would be similar accross systems the more that
the details are hidden.  A win32 user or a Unix or Java user might port these functions with the same names and
differing uderlying construction that is not visible to the user (i.e. not Mac APIs).  I admit it is a leap to think
that Perl users of different platforms would collaborate in this way, but why not?

It is true that many GUI functions would not be implementable this way, but that's what the Toolbox modules are for.
They are for platform specific functions. and for the absolutely most complete control.



# ===== Want to unsubscribe from this list?
# ===== Send mail with body "unsubscribe" to macperl-request@macperl.org