In this case, I prefer having a nice, ugly name with something like unsafe or unchecked in it. And, I want it at the point the unsafe/unchecked operation is being done. For production code, it's important for whoever wants to understand (i.e., maintain) it later to know the intent and its implications. Changing between them (generally) should not be a trivial decision.
Doug On Mon, Sep 7, 2009 at 12:11 PM, Faré <fah...@gmail.com> wrote: > Maybe it's better to keep the very same name as the safe operation, > and let whoever imports it choose a different prefix. The immediate > benefit is that switching from safe to unsafe becomes trivial, which > is great for developing and testing in safe mode but delivering and > running in unsafe mode. > > What will be interesting is to see if TypedScheme modules allow to > squeeze extra performance by expanding to unsafe operations. > > [ François-René ÐVB Rideau | Reflection&Cybernethics | > http://fare.tunes.org ] > If it's not worth doing right, it's not worth doing. -- Scott McKay > > > > > 2009/9/7 Carl Eastlund <carl.eastl...@gmail.com>: > > On Mon, Sep 7, 2009 at 1:59 AM, Doug > > Williams<m.douglas.willi...@gmail.com> wrote: > >> One other thing that is really just semantics. > > > > Actually, that's just syntax. ;) > > > > On this list, semantics is the important stuff. > > > >> Would it be better to call > >> the operations 'unchecked-<whatever>' instead of 'unsafe-<whatever>'? > >> Generally, we are calling the function because we know it is safe to > avoid > >> some constraint check - not because it is unsafe. Just a nit. > > > > --Carl >
_________________________________________________ For list-related administrative tasks: http://list.cs.brown.edu/mailman/listinfo/plt-dev