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

[ilir topalli <ilir@gis.net>]

Chris Nandor wrote:

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

I think we are in agreement here. I'm saying that it would be nice if there were
many alternatives
to the standard toolbox just like this.   Toolbox functions have there place but
there needs to be alternatives.
Sometimes you want to move the text over one pixel and sometimes you don't care.

There may even be a time where you'd want to make a control button that's
smaller than the text in it...
although I really couldn't imagine why.

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

1- a system that is as similar to the Toolbox routines as possible and where
different clearly described
2- modules that use the toolbox in a simplified manner

Your right, I agree the term is vague and we should definitely drop it.  Sorry
to use such a vague term.
It seems however that we also are a bit vague on the term "different".


What I am hearing is that the perl toolbox is different in that it is
implemented in Perl and perl handles them in its own way
(such as the way it handles constants and functions)
I am also hearing is that the toolbox modules are very similar to the apple
toolbox routines
I can agree with that.
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
do things in perl?

If so The toolbox routines were created by Apple which did not have any
consideration of Perl in mind when they designed
This is why so many people stick to standard Perl and avoid using them.  (That
and the fact that documentation is sparse, and that apart from being a list of
terms the shuck information is not terribly useful).




I agree on this.

diff: perl like
same: perl like, toolbox like


Clearly the Perl toolbox and the Inside Mac version

I don't mean that they don't seem to be written in Perl.  The routines are
indeed different from the way Inside Mac describes them because Perl is
different.  In fact, that in itself is daunting as I had assumed that they were
the same and had to spend a lot of time trying to figure out how different they
were.  Perhaps it is easier for a seasoned Perler to know how to handle these
things.  Many experienced Perl programmers have had some difficulty as well and
most avoid using the Toolbox whenever possible.  I think the programming culture
of Perlers is often very different from the programming culture that developed
the toolbox.  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".

The toolbox routines were created by Apple which did not have any consideration
of Perl in mind when they designed
This is why so many people stick to standard Perl and avoid using them.  (That
and the fact that documentation is sparse, and that apart from being a list of
terms the shuck information is not terribly useful).



After making a time investment in learning Perl, many would prefer not to have
to make a much larger committment to learning a huge text such as  Inside
Macintosh.  Although it would be great if everyone did, I think it creates a
barrier to entry into these functions.  It's a shame since as macintosh users
such things as the GUI and events should be the first things we experiment
with.  It's what makes MacPerl such a valuable resource.


Hopefully there will be an alternative that won't require users to be
responsible for so much

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


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