[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: New Lisp ?
- To: address@hidden
- Subject: Re: New Lisp ?
- From: Andreas Bogk <address@hidden>
- Date: Fri, 4 Jan 2002 09:05:08 -0500 (EST)
- References: <c571739c.0112211614.24569c07@posting.google.com> <okfg064ugsh.fsf@bellsouth.net> <3218011993496537@naggum.net> <okf4rmjv2n6.fsf@bellsouth.net> <3218025363470352@naggum.net> <slrna2acon.8d1.markj+0111@cloaked.freeserve.co.uk> <c571739c.0112222317.3d2be7fd@posting.google.com> <slrna2b8q0.1bm.markj+0111@cloaked.freeserve.co.uk> <c571739c.0112230535.2dd6f1b1@posting.google.com> <scoc2u4qkpue4mt9irr0cldu5ig913qogr@4ax.com> <l91d2ucqplfm9auo2gi20pd74ktnl2utlp@4ax.com> <ni8f2uck3ua78ucps9kg9c4sal2g38r85v@4ax.com> <87vgew4631.fsf@teonanacatl.andreas.org> <3C27C7BC.DECCE7DB@quiotix.com> <87pu542jjz.fsf@teonanacatl.andreas.org> <3C27D85C.9E5FE363@quiotix.com> <87ellk9el3.fsf@teonanacatl.andreas.org> <3C28500F.6652B4EB@quiotix.com> <874rmf3x4c.fsf@teonanacatl.andreas.org> <okfsn9xs9do.fsf@bellsouth.net> <877kr9l24k.fsf@teonanacatl.andreas.org> <3C2AB04C.F4586FA8@quiotix.com>
- Sender: address@hidden
- User-agent: Gnus/5.0806 (Gnus v5.8.6) XEmacs/21.4 (Civil Service)
- Xref: traf.lcs.mit.edu comp.lang.scheme:38380 comp.lang.lisp:78262 comp.lang.functional:29643 comp.lang.dylan:13883
Jeffrey Siegal <jbs@quiotix.com> writes:
> What happens in Java is that you have to at least declare the exceptions
> up the chain anyway (the compiler will reject a method that doesn't
Yes, and that bothers me to no end. I want to have specific code that
knows about an exception in exactly two places: where it is generated,
and where it can be handled. All the code inbetween doesn't need to
know more than that an operation has failed and that it needs to clean
up.
> Yes and no. They're not "regular objects" because they can't be
> subclassed.
That's true. The point of sealing is to offer the option of turning
off certain OO features while retaining the benefits of others (the
user can still specialize his own generic functions on integers, for
instance).
> I think what you'd see in any kind of production
> environment if Dylan were used is that almost everything would get
> sealed off, much the way a lot of Java code makes extensive use of
> "final." At that point, you might as well just use a static block
> compiler and let the compiler recognize what is subclassed and what
> isn't.
I'd hate to use a static block compiler, the turnaround time would be
a nightmare. And I'd like to keep the option of adding classes and gf
methods at runtime.
Adreas
--
"In my eyes it is never a crime to steal knowledge. It is a good
theft. The pirate of knowledge is a good pirate."
(Michel Serres)