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

[Matthew Langford <langfml [at] eng [dot] auburn [dot] edu>]

On Wed, 10 Nov 1999, ilir topalli wrote:

> 
>  Is what your saying that the toolbox modules are implemented as similarly to
> the Inside Mac Specifications as possible and that still jives with the way
> people
>  like to do things in perl and what attracts people to Perl?

yes, both of those can be true

>  If so I can't really agree. (If not I don't mean to put words in your mouth).
>  And maybe we don't need to agree on this, but if so,

The Toolbox routines are meant to allow as much access as possible to the
functions that Apple provides with the operating system.  They should (and
pretty much do, IMO) exhibit a nearly 1:1 correspondence with the actual
function definitions, as far as the different languages and data types
will allow.

They are not what you want, in terms of a nice object framework wrapped
around the Toolbox.  Why?  Because in my estimation this would be as much
work as the rest of MacPerl--a vast effort.

It is not easy, as easy as other pieces of Perl, but Perl is not uniformly
easy to learn.  There are many Perl modules which exist solely to provide
access to some external capability (databases, operating system calls,
etc).  If the external capability is complex, the best the interface can
do is provide easy, straightforward access to that complexity.  Your
grievance is more against the Toolbox than Perl's interface to it, and
perhaps against the Toolbox only because you want it to be what it is
not--a high level Visual MacPerl app builder.


> 
>  1)  Surely more people would use the toolbox than do.
>  Maybe some people with a programming background that is heavy in the toolbox
> department are used to handling things this way.

Absolutely, if you build a Visual MacPerl framework, you would no doubt
increase the number of Toolbox users.  Everybody supports this.  But you
should realize the effort involved:  much, much more than Perl-ifying the
Toolbox functions.

>  It seems that this would be why so many people stick to standard Perl
> and avoid using them.  (That, and the time investment in learning the
> toolbox and learning the toolbox really is like learning another
> language).

Absolutely, it is complicated.  Now, what you ask is that someone master
this complicated beast, and simplify it (which always implies a broad and
deep understanding, as well as a vision of how to present the whole
thing).  Then, they must write a large amount of code.

Nobody is against this, but nobody has volunteered for it either.  


> At  the very least, Inside Macintosh is not about "more than one
>  way to do it"  it is about "there is only one way to do it".  At
> present there really is only one way to implement the toolbox.

Actually, the Toolbox is about allowing every possible useful way of doing
anything (within bounds) a program needs to do.  The sample code is just
one way to do it (getting things right is complicated enough that most
people don't care to search out another). 

There _is_ only one (general) way to implement Toolbox wrappers, because
if you did it differently, it would be something else:  a high level
framework, perhaps, or your own GUI toolkit.


> 
>  Although useful and sometimes necessary I and many many experienced Perl
> programmers tell me that they have had some difficulty and
>  most perlers seem to avoid using the Toolbox whenever possible.
>  I was amazed at how easy it was to get up and running in Perl.  The Apple
> specific stuff however is a different story.

Right.  The Toolbox is very complicated.  No way around it, except by a
very large amount of work, which no one has volunteered to do.  Feel free
to write a Visual MacPerl, or MacPerl Swing, or MacPerl Tk, or MacPerl X.

> 
>  It's a shame too.  I think the first thing MacPerlers should be
> experimenting with is the GUI and events.  The toolbox and the
> Mac:Whatever modules is what makes MacPerl special.

It makes MacPerl different from Perl, and they are very handy.  But (as
I've been told on this list) doesn't it make sense to use MacPerl to do
Perl things, rather than trying to make it something regular Perl is not?
Still, it is fun to see what can be done.  And I won't complain if you can
pull some wizardry.

Don't criticize a camel because it is not, uh, an apple.  It just isn't.

If you want a high-level framework, build it and many may use it.
Short of that effort, you could pick some piece of the Toolbox, and
simplify that, as Chris Nandor has done for AppleEvents.  Sound, for
example, or serial communication, or the speech manager, or the control
manager, or windows.  Whatever piece you use and understand, and have a
vision for simplifying.  This is realistic.  Some members of this list 
have this level of understanding and interest, and are doing this. 

>  I think Perl could evolve into a tremendous general purpose
> development tool if it could handle GUI or other graphics as simply
> and powerfully as it does text. I guess parsing HTML is a step in this
> direction, but controling a second language has its obvious problems

If you can accomplish this, go to it.  It is a difficult task, and not 
many other MacPerl people will share this vision enough to shoulder the
task of writing the code.  They use MacPerl for other things.  Delphi
MacPerl, Visual MacPerl, MacAppMacPerl, MacPerl Tk,...lofty vision.  Lots
of work and distance between vision and present reality.  My advice is to
tackle something much smaller first.


>  I guess porting of Tk would be a good step in that direction.  I have
> very little experience with it though. Does Tk also use Controls etc?  
> All I know is that a lot of people seem to really dislike using it (at
> least Mac users).

Tk is a solution to a different problem:  how to generalize X Windows
using the tool command language.  Unfortunately, it hasn't evolved all
that much to accommodate different platforms (it still has X-centric bias,
IMO), and the tcl root has a different mindset.  


--
MattLangford 



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