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

[Chris Nandor <pudge@pobox.com>]

At 14.33 -0500 1999.11.10, ilir topalli wrote:
>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.

Actually, print() does none of these things, at all.  print only sends
characters to a filehandle.  On Windows perl, print() does do newline
conversion.  Aside from that and buffering, there is almost no
"intelligence" in print() at all, and not significantly different from
printf in C, except in the obvious (you can embed variables in perl's
print).


>It's a very friendly language
>and I beleive that's what attracts a lot of people.  Compare this to
>DrawString().

Yes, DrawString() _should_ be much more complex, because it _is_ much more
complex.


>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.

Sure, but I still don't see them as not Perl-like.  They are just more
complex.  It seems we just have different views of what "Perl-like" is.  So
we will just drop that phrase and move on.  :)


>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?

The underlying API is too different.  Rather than focus on some
cross-platform GUI API which probably wouldn't work very well, I'd rather
someone port Tk to MacPerl.  Especially since there is no way you could get
people to switch to a new API just because that is what we are using with
MacPerl.

The reason I say I don't think it would work, that the API is too
different, is because I have done GUIs with the Tk and Mac OS APIs, and I
once had thoughts of adapting the Tk API to sit on top of the Mac OS API,
and after doing some Tk, I realized the concepts just didn't map well
enough to make it seem worth the effort of doing it or even using it.

-- 
Chris Nandor          mailto:pudge@pobox.com         http://pudge.net/
%PGPKey = ('B76E72AD', [1024, '0824090B CE73CA10  1FF77F13 8180B6B6'])

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