engber@shorty.CS.WISC.EDU (Mike Engber) (01/27/89)
In the December '86 issue of MacTutor (also Apple Tech Report #6) Ken Doyle wrote an articl on object Pascal in which he warns that using the with statement on objects is dangerous in the same way using a with statement on an unlocked handle is dangerous. This is because object variables are really handles. (made to syntactically resemble normal variables) In the definition of Object Pascal they extended the definition of the with statement to include its use with object. If Doyle's warning applies, this seems pretty silly. Note: I'm taking the point of view of 'vanilla' Object Pascal programming, no HLock to help me out. I know the term 'vanilla' Object Pascal may seem self contradictory, but Apple did get their definition published in 'Structured Language World' so I assume they have some interest in it being accepted elsewhere. Also, for similar reasons Doyle warns against using an object's field as a var parameter. The language definition seems to allow it, if it is a problem then I have the same complaint again. The answer to my question is probably compiler specific. A clever compiler could have implented Object Pascal so that Doyle's warning were not applicable. I use LSP. Are you listening Rich? -ME
siegel@endor.harvard.edu (Rich Siegel) (01/27/89)
In article <7096@spool.cs.wisc.edu> engber@shorty.cs.wisc.edu (Mike Engber) writes: > >The answer to my question is probably compiler specific. A clever >compiler could have implented Object Pascal so that Doyle's warning >were not applicable. I use LSP. Are you listening Rich? I assume that "are you listening Rich" means "Why isn't Lightspeed Pascal clever enough to do this", right? 1) Because of the way that objects are implemented (as memory blocks), they are best allocated as relocatables, since the Mac memory manager works best with relocatable blocks. MPW Pascal uses the same scheme for allocating objects. 2) In Object C, it is possible to label an object "direct", which makes the programmer responsible for the storage management of his objects. Given that freedom, how would you recommend implementing objects? In other words, the question isn't compiler-specific, it's OS-specific. (Actually, it's pretty Mac-specific; I don't know of Object Pascal implementations on any other system.) --Rich Rich Siegel Staff Software Developer THINK Technologies Division, Symantec Corp. Internet: siegel@endor.harvard.edu UUCP: ..harvard!endor!siegel Phone: (617) 275-4800 x305 Any opinions stated in this article do not necessarily reflect the views or policies of Symantec Corporation or its employees.
lsr@Apple.COM (Larry Rosenstein) (01/28/89)
In article <7096@spool.cs.wisc.edu> engber@shorty.cs.wisc.edu (Mike Engber) writes: >In the December '86 issue of MacTutor (also Apple Tech Report #6) Ken >Doyle wrote an articl on object Pascal in which he warns that using the >with statement on objects is dangerous in the same way using a with I don't have the article in front of me, so I don't know what Ken wrote. It could be that his comments were applicable to the MPW Pascal compiler at the time. The 3.0 compiler either handles all these problems correctly, or gives you a compile-time warning. For example if you write: with object1 do begin field1 := NewHandle(109); field2 := NewHandle(108); field3 := NewHandle(107); end; the compiler will put the handle that is object1 in a register and dereference it each time it does the assignment. If you write: with object1 do begin field1 := handle1; field2 := handle2; field3 := handle3; end; then the compiler sticks a pointer to the fields in a register and does the assignments with 3 indexed stores. It can do this because the body of the with statement contains no procedure calls. If you write: object1.field1 := NewHandle(10); object1.field2 := handle2; object1.field3 := NewHandle(20); the compiler will explicitly dereference the object handle after calling NewHandle, but will directly store into the object for the 2nd assignment (since the pointer to the object's fields is still in a register at that point). Both of these examples were ones that I just tried with the standard 3.0 MPW Pascal compiler. >Also, for similar reasons Doyle warns against using an object's field as >a var parameter. The language definition seems to allow it, if it is a >problem then I have the same complaint again. In this case, the MPW compiler gives you an error at compiler time (unsafe use of a handle). The 3.0 compiler also catches the case where you pass a field of an object as a non-VAR parameter, but the size of the paramter is more than 4 bytes. In these cases, the compiler still passes a pointer to the field, which would be as unsafe as a VAR paramters. The MPW Pascal compiler has a compile time switch to turn off these error checks, if you know the procedure you are calling can't compact memory.
duggie@Jessica.stanford.edu (Doug Felt) (01/31/89)
Excuse me if I'm wrong, but I seem to remember that early implementations of the standard C libraries used the memory manager rather naively to implement things like malloc, with the result that malloc had rather high overhead both in terms of time and space. Later implementations allocated larger chunks of memory and malloc'ed out of those, and obtained siginificant speed improvements. It seems this would be relevant to the development of object-oriented flavors of C on the Mac, and whether objects should be memory manager handles or malloc'ed out of larger chunks of memory. It may be that message dispatch overhead outweighs the overhead of GetState/HLock/HUnlock, or that objects are so relatively persistent that using the memory manager to allocate new objects via NewHandle is not significant. Has someone investigated this? And speaking of method dispatch... Doug Felt Courseware Authoring Tools Project Stanford University
oster@dewey.soe.berkeley.edu (David Phillip Oster) (01/31/89)
A naive implementation of malloc() calls NewPtr(). NewPtr() does a heap shuffle to try to put the allocated block at the low end of the heap. The shuffle is slow. NewHandle() doesn't do a shuffle, so it is fast. Object oriented extensions are usually implemented out of handles, so they are fast.
pcraig@maths.tcd.ie (Peter Craig) (02/03/89)
In article <7096@spool.cs.wisc.edu> engber@shorty.cs.wisc.edu (Mike Engber) writes: >Doyle wrote an articl on object Pascal in which he warns that using the >with statement on objects is dangerous in the same way using a with >statement on an unlocked handle is dangerous. This is because object >variables are really handles. (made to syntactically resemble normal ............... > >Also, for similar reasons Doyle warns against using an object's field as >a var parameter. The language definition seems to allow it, if it is a >problem then I have the same complaint again. > If you use MPW Object Pascal on the Mac, the allocation system for objects is under your control. You can change the routine which allocates objects. It goes by the name %OBNEW or some such thing. The 'object' still must be a handle to the data area, but it need not be a Macintosh Memory Manager handle. Specifically it need not be relocatable, or you could arrange for objects to be relocatable only during a garbage collect routine which you would run at 'safe' times. I had to get into this because I wished to have a very large number of objects for a statistical graphics application. Each data point is a separate object. Unfortunately the Mac Memory Manager gets very upset if you allocate too many separate blocks of memory and the machine then runs very slowly. Most, but not all, of the objects in my program are descendants of TFunnyObject (my own class) which behaves exactly like TObject except the allocation is done differently. This has worked very successfully. The only problem is that I have been rather lazy since I have sufficient memory and I haven't really bothered to write stuff to allow memory compaction etc. However it should be pretty easy to do, if I ever need to do it. Your difficulty above arises from confusing handles with relocatable handles, which is understandable given that the basic reason for using handles in the first place is to allow some of them to be relocatable. Peter Craig Peter Craig, Dept. of Statistics, Trinity College, Dublin 2, Ireland 353-1-772941 (x. 2048 or 1203) pcraig@maths.tcd.ie
siegel@endor.harvard.edu (Rich Siegel) (05/11/89)
I'm kind of curious about the perception and uses of Object Pascal, so to scratch the itch, here are some questions: - Do you use Object Pascal at all? - If so, why? - If not, why not? - Do you use MacApp? - If so, why? - If not, why not? - What Pascal compiler do you use? Responses can go to this newsgroup; I'm interested in a discussion. --Rich ~~~~~~~~~~~~~~~ Rich Siegel Staff Software Developer Symantec Corporation, Language Products Group Internet: siegel@endor.harvard.edu UUCP: ..harvard!endor!siegel "She told me to make myself comfortable, so I pulled down my pants and sat in the pudding." -Emo Phillips ~~~~~~~~~~~~~~~
mnkonar@gorby.SRC.Honeywell.COM (Murat N. Konar) (05/11/89)
In article <1794@husc6.harvard.edu> siegel@endor.harvard.edu (Rich Siegel) writes: > > - Do you use MacApp? No. > - If so, why? > - If not, why not? Because the compiler I use and love doen't support it. > > - What Pascal compiler do you use? THINK's Lightspeed Pascal 2.x (you kind of walked right into that one, eh? When do we get MacApp support?) ____________________________________________________________________ Have a day. :^| Murat N. Konar Honeywell Systems & Research Center, Camden, MN mnkonar@SRC.honeywell.com (internet) {umn-cs,ems,bthpyd}!srcsip!mnkonar(UUCP)
peirce@claris.com (Michael Peirce) (05/11/89)
In article <1794@husc6.harvard.edu> siegel@endor.harvard.edu (Rich Siegel) writes: > > I'm kind of curious about the perception and uses of Object Pascal, >so to scratch the itch, here are some questions: > > - Do you use Object Pascal at all? YES > - If so, why? 1: to use MacApp 2: it allows me to build programs in a more abstract, modular way > > - Do you use MacApp? YES > - If so, why? 1: to leverage off all the knowledge that is packed into the MacApp code. They check for so may cases of problems that I would overlook unless I spent LOTS of time thinking about it -- and then probably I'd get it wrong. 2: MacApp seems to be a very well thought framework. I saves me the trouble of inventing it all myself. In areas where I disagree with it's approach, I just override things or don't use the supplied classes. Of course, this works best if you agree with MacApp most of the time. 3: I'm lazy and love to use all the supplied classes and get something that not only works, but works well (undo, save, etc) in a very short amount of time. 4: It really does seem to be more maintainable ONCE YOU LEARN THE SYSTEM. The first few times you look at MacApp code it looks like a mess, but eventually it really does all start to make sense. > > - What Pascal compiler do you use? MPW Pascal > > --Rich >~~~~~~~~~~~~~~~ > Rich Siegel > Staff Software Developer > Symantec Corporation, Language Products Group > Internet: siegel@endor.harvard.edu > UUCP: ..harvard!endor!siegel Claris Corp. | Michael R. Peirce -------------+-------------------------------------- | 440 Clyde Avenue | Mountain View, CA 94043 | (415) 960-4011 | MCI-Mail: mpeirce | AppleLink: peirce1 | Internet: peirce@claris.com | uucp: {ames,decwrl,apple,sun}!claris!peirce
g556871349ea@deneb.ucdavis.edu (0040;0000059882;0;745;352;) (05/11/89)
In article <1794@husc6.harvard.edu> siegel@endor.harvard.edu (Rich Siegel) writes: > > I'm kind of curious about the perception and uses of Object Pascal, >so to scratch the itch, here are some questions: > > - Do you use Object Pascal at all? > - If so, why? > - If not, why not? As a graduate student employed as a Research Assistant in a university}i, it is not not feasible to use Object Pascal because: (1) when teaching, it's unreasonable to expect students to be at that level (2) my Prof doesn't understand it and so won't buy it (3) I sure can't afford it especially if I make a decent application, I can't sell it because it belongs to the university > > - Do you use MacApp? > - If so, why? > - If not, why not? Would really like to use it except there's no coordination between UCD and Apple/APDA to be able to purchase MacApp. What? UC Davis is going to join APDA? Too much hassle thanks. So long as this situation exists, I don't think MacApp will make it big as a major platform here. I hear LSP has some object programming capabilities. I suppose that it is a viable alternative but we're currently locked in to Turbo because there's a version for Ms-DOS too. Stupid reason, but there's plenty of those around here. Another problem is a lack of academic prices. Turbo has an academic price. Just a suggestion, that's all. I do use Turbo for teaching a class in chemical model programming. > > - What Pascal compiler do you use? > >Responses can go to this newsgroup; I'm interested in a discussion. > > --Rich >~~~~~~~~~~~~~~~ >kRich Siegel > Staff Software Developer > Symantec Corporation, Language Products Group > Internet: siegel@endor.harvard.edu > UUCP: ..harvard!endor!siegel > > "She told me to make myself comfortable, so I pulled down my pants > and sat in the pudding." -Emo Phillips >~~~~~~~~~~~~~~~ Colin Ong Graduate Student Slave Labor Dept. LAWR University of California Davis INTERNET: g556871349ea@deneb.ucdavis.edu BITNET: cgong@ucdavis Disclaimer: All the standard things.
ken@uf.msc.umn.edu (Kenneth Chin-Purcell) (05/11/89)
<1794@husc6.harvard.edu> siegel@endor.harvard.edu (Rich Siegel) writes: > I'm kind of curious about the perception and uses of Object Pascal, >so to scratch the itch, here are some questions: > - Do you use Object Pascal at all? > - Do you use MacApp? > --Rich I started with Object Pascal using the old TML compiler and my own shell. A month afterwards MacApp came out, and I switched to MPW Pascal and MacApp. The program I was working on, Lincages, turned into my Master's thesis. Lincages synthesizes four bar mechanisms. It's for mechanical engineers who need to quickly design a linkage that performs a certain motion, like opening a door or moving a tray. Since it's on a Macintosh it has cute features, like animation and resizable links. The program broke up into objects (links, pivots, dyads, etc.) quite nicely. MacApp made it practical for me to write Lincages on my own, as a research project. The Lincages code is about 30,000 lines. Although I battled with some of MacApp's structure, and wound up switching a couple of lines in the MacApp source, MacApp certainly made Lincages a better program. Now that I have a job, my world is Suns, Crays and X windows. I still diddle at home though with LSP, and have dusted off my old shell from the TML days. Even if MacApp and LSP become compatible, I might stick with my own stuff. As far as object oriented programming goes, I've been born again and can never go back. I would drop Object Pascal for C++ though. -- -- Ken (aka ken@msc.umn.edu)
hpoppe@bierstadt.ucar.edu (Herb Poppe) (05/11/89)
In article <1794@husc6.harvard.edu> siegel@endor.harvard.edu (Rich Siegel) writes: > > I'm kind of curious about the perception and uses of Object Pascal, >so to scratch the itch, here are some questions: > > - Do you use Object Pascal at all? No, but I would like to. > - If so, why? > - If not, why not? Even though my compiler supports Object Pascal, its documentation is inadequate for me to undestand how to program with it. > > - Do you use MacApp? No, but I would like to. In fact, Apple has been making noises that sound like it will be necessary to use OOP in order to develop with some future version of the MacOS. > - If so, why? > - If not, why not? Even though my compiler supports Object Pascal, it doesn't support MacApp because of the way they handle segmenting: my compiler allows only one segment per file; MacApp files can contain many segments. > - What Pascal compiler do you use? THINK's Lightspeed Pascal 2.0. . > Rich Siegel > Staff Software Developer > Symantec Corporation, Language Products Group I looked back through old issues of MacUser. The earliest ad for LSP 2.0 I found was August '88. The copy reads, in part: "How about new Object Pascal support. For object oriented programming. And soon, MacApp(TM)!" Well, how about it! The compiler may support Object Pascal but the documentation doesn't. 9-10 months have passed since Symantec promised MacApp for LSP and they have yet to announce its availability. Since it will probably take at least 3 months to deliver after announcing, more than a year will have passed. I don't think that qualifies as "soon". I liked LSP 1.0. I love LSP 2.0. BUT I WANT MACAPP! Please don't make me buy MPW (gack). (Thanks for asking the question Rich; please take our responses and use them to club your management.) Herb Poppe NCAR INTERNET: hpoppe@ncar.ucar.edu (303) 497-1296 P.O. Box 3000 CSNET: hpoppe@ncar.CSNET Boulder, CO 80307 UUCP: hpoppe@ncar.UUCP
liberte@zaphod.ncsa.uiuc.edu (05/12/89)
I would use the object capability in Lightspeed Pascal, if I could use it with the C code I must live with. (Even if I compile the C code in Lightspeed C, build a library, etc, that fails because the C code uses C libraries that are incompatible with the LSP libraries.) So I must use C, and C++ is even further out of reach than Object Pascal. Sigh... Dan LaLiberte National Center for Supercomputing Applications liberte@ncsa.uiuc.edu
cbm@well.UUCP (Chris Muir) (05/12/89)
One of the things that I was looking forward to about LSP 2.0 was the Object
Pascal and MacApp support. I can tolerate needing more time to do MacApp, but
shipping a product with Object Pascal support and no documentation (except
your ObjectDraw program) is sloppy. Because of this I haven't done much of
anything with Objects. Maybe when I get some time to go fishing in the dark...
--
_______________________________________________________________________________
Chris Muir | "There is no language in our lungs
{hplabs,pacbell,ucbvax,apple} | to tell the world just how we feel"
!well!cbm | - A. Partridgetom@unicads.UUCP (Tom Gerardy) (05/13/89)
In article <1794@husc6.harvard.edu> siegel@endor.harvard.edu (Rich Siegel) writes: > > - Do you use Object Pascal at all? Absolutly! Given the choice I'd use C++ though. I use C++ at work and so I get a lot of practice! > - If so, why? > - If not, why not? Certain problems fit very well into an object oriented paradigm. Using an object oriented language in those cases leads to _much_ more readable code. We actually did our event dispatching via proc ptrs in an "object" pointed to by the refcon before THINK had object support, but the code is actually readable now and doesn't contain any inline assembly code! > - Do you use MacApp? I've played with it some, but not enough to feel comfortable with it yet. > - If so, why? > - If not, why not? MacApp is a large environment. The learning curve is very steep to begin using it. I don't doubt it's usefulness, its just hard to get up to speed. The smalltalk environment has the same problem. > - What Pascal compiler do you use? I use both THINK and MPW (both in Pascal and C). The LSP debuggery is much nicer, but I haven't upgraded to MPW 3.0 yet so I can't compare it to SADE. On the other hand I like the scripts and tools I get in the MPW world. Sigh... someday I'll find the ultimate environment :-) > --Rich >~~~~~~~~~~~~~~~ > Rich Siegel > Staff Software Developer > Symantec Corporation, Language Products Group > Internet: siegel@endor.harvard.edu > UUCP: ..harvard!endor!siegel > -- - Tom Gerardy UUCP: ...!sun!sunpeaks!unicads!tom UNICAD, Inc. or: ...!ncar!{sunpeaks|boulder}!unicads!tom 1695 38th Street Boulder, Colo. 80301 (303) 443-6961
mce@tc.fluke.COM (Brian McElhinney) (05/13/89)
siegel@endor.harvard.edu (Rich Siegel) writes: > - Do you use Object Pascal at all? > - Do you use MacApp? I bought MPW and Object Pascal only because of MacApp. In spite of the advantages of MacApp, the slowness of MPW forced me to switch to LSC. It's really a shame, because MacApp is something Macintosh software developers have needed since day one. It has not caught on because most people just plain prefer C, and MPW itself is overwhelming (in complexity, expense and slowness). IHMO, you could make a *lot* of money selling a C++ compiler, similar to LSC, if it also worked with MacApp. I know that's a tall order, but the opportunity is there and I hope someone takes advantage of it. Brian McElhinney mce@tc.fluke.com
Greg_Mark_Finnegan@cup.portal.com (05/14/89)
Rich, Were you at the Mac Developers Conference last week? Every seminar from Apple mentioned MacApp (even though the future direction in the 'official' Apple programming language is C++). The MacApp sessions were pretty full and when David Neal mentioned that MacApp support in LSP (oops THINK) Pascal was the Pascal group's number one priority, I though he was going to get a standing ovation. Greg.
rick@Jessica.stanford.edu (Rick Wong) (05/16/89)
In article <1794@husc6.harvard.edu> siegel@endor.harvard.edu (Rich Siegel) writes: > - Do you use Object Pascal at all? Yes, for MacApp. > - Do you use MacApp? > - If so, why? Yes. Except for the slow turnaround time and the lack of a source-level debugger that understands objects, MacApp is the _best_ application- development platform for the Mac. Consider the usual litany of things MacApp handles for you: * the event-loop * windows * menus * scrolling AND autoscrolling * failure handling * filing * memory management * the clipboard * undo * printing * multiple documents MacApp also provides several view classes that are far easier to use than their Toolbox counterparts: control views (buttons, scrollbars, etc.), dialog views, a text-editing view, and grid/list views. As any Macintosh programmer will tell you, implementing all of these things using just the Mac Toolbox, _in conformance with the Macintosh user inter- face guidelines_, takes an inordinate amount of work. While I'm on my soapbox, I'd like to dispute a common myth about MacApp's learning curve. Many people claim it's slow, but compared to what? When I think about how much time it used to take me to get windows to scroll, or to write my own filing package, and I compare it with learning object- oriented design techniques and MacApp's class hierarchy, I think MacApp's a pretty good deal. In addition, many of the skills you learn with MacApp are applicable to other object-oriented toolkits (for instance, there's a good deal of overlap between MacApp and NeXT's AppKit). > - What Pascal compiler do you use? MPW. I would only use another compiler if it allowed me to use code writ- ten in other languages (C, C++, assembly). > Rich Siegel Rick Wong Courseware Authoring Tools Project, Stanford University rick@jessica.stanford.edu
hammersslammers1@oxy.edu (David J. Harr) (05/27/89)
--- Do you use Object Pascal at all?
No, because I couldn't find very substantial documentation for it anywhere
outside "OOP on the Macintosh" and I didn't feel like paying the ~$30 for
the book whenb it was mostly concerned with MacApp, which I don't have.
--- Do you use MacApp?
No, because the compiler I like doesn't support it (can you say LSP?)
--- What Pascal compiler do you use?
This is a trick question, right? (8 :-))