suzanne.soy/racket
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
14,576 Commits 17 Branches 54 Tags 278 MiB
09425bc801
Commit Graph

83 Commits

Author SHA1 Message Date
Stevie Strickland
09425bc801 Keep the original class in the supers list. Also, copy over the no-super-init? 
flag.

svn: r18296
 2010-02-23 12:51:27 +00:00
Stevie Strickland
e4f7f0032e Get rid of the loop that's no longer a loop, and also add in the necessary 
object unwrapping.

svn: r18288
 2010-02-23 04:13:09 +00:00
Stevie Strickland
978a9586f5 We no longer need the #:error thing here, because we've fixed object-contract 
for real now.

svn: r18286
 2010-02-23 04:02:03 +00:00
Stevie Strickland
14ab0175c3 Okay, expanding field accesses and mutations to basically inline the 
unwrapping operation helps a bit, especially with inherited fields.
Unfortunately, as one might expect, TANSTAAFL applies here.  In order
to make sure that we keep the contracted objects around as much as
possible to make sure there are no holes, we end up making local and
inherited field access codes 2-3x more than they did before.  However,
this is still something on the order of 5x faster than external
access.  But blah.

CONTRACTS ARE NOT FREE.  Just ask your local lawyer.

svn: r18285
 2010-02-23 03:15:43 +00:00
Stevie Strickland
53381bbf03 Remove unwrapping in find-method/who until I figure out what I actually need 
to do.

Also fix up is-a? and subclass? so that they should work the same when
contracts are removed from a program.

svn: r18282
 2010-02-23 01:15:11 +00:00
Stevie Strickland
f1b0bfdd79 Yeah, accessors need arguments. 
svn: r18281
 2010-02-23 00:46:47 +00:00
Stevie Strickland
cfdb9dd39b Time to unveil object/c. 
svn: r18280
 2010-02-23 00:43:25 +00:00
Stevie Strickland
ab2561e08a Now we don't need to recur down to unwrap something, but if we get a wrapped 
primitive object in a method send, we need to unwrap all objects for its
method.

svn: r18279
 2010-02-23 00:40:59 +00:00
Stevie Strickland
2af44afb17 Now I see -- I was handling local fields in an incorrect manner. We don't 
want later projections to affect local accesses or mutations -- so we just
have to add the unwrap check in case it's a wrapped object.

svn: r18277
 2010-02-22 22:43:47 +00:00
Stevie Strickland
0e3af71176 So now object-contract works again, but we seem to have introduced a bug 
in the class/c inherit-field form, so now time to fix that.

svn: r18276
 2010-02-22 22:26:27 +00:00
Stevie Strickland
a3a1d0d9c7 Fix shadowing in make-wrapper-class. Now delay lookup for 
accessors/mutators used for internal field access.  This fixes public
fields, but not private fields.  Next should fix that up.

Will definitely need to benchmark all this delay though.

svn: r18275
 2010-02-22 22:10:30 +00:00
Stevie Strickland
d820493feb First cut of converting object-contract to share a common base that 
object/c will also use.

svn: r18274
 2010-02-22 21:55:32 +00:00
Stevie Strickland
815dd80923 Sync up to catch my fix. 
svn: r18270
 2010-02-22 20:58:53 +00:00
Stevie Strickland
11b8fd4204 Fix vector creation for internal field access. 
svn: r18269
 2010-02-22 20:57:36 +00:00
Stevie Strickland
c2fcdbba65 Class Contracts Phase 2: Object/c Boogaloo 
This isn't just a copy of trunk r18264 -- it has a slight difference in how
local field accessors and mutators are handled that will eventually play a
larger role.

svn: r18265
 2010-02-22 19:09:42 +00:00
Stevie Strickland
a0769da5ea Add the contract shorthands for -> and ->* to use for methods where we don't 
care about properties of this.

svn: r18248
 2010-02-21 02:54:06 +00:00
Stevie Strickland
ffa34e1f7d Add augride, which is like augment but enables the contract writer to give 
subclasses an idea of whether a method can be augmented (augment) or whether
a method augmentation can be overridden (augride).

svn: r18240
 2010-02-21 00:17:42 +00:00
Stevie Strickland
f72ca7bb1b Now inherit works (and tests!) 
svn: r18237
 2010-02-20 22:54:11 +00:00
Stevie Strickland
370792b881 Refactoring done, and I think that's actually cleaned up things a bit. Now 
to handle inherit.

svn: r18236
 2010-02-20 22:44:53 +00:00
Stevie Strickland
b589c3c230 More preparation to move all the int-method/dynamic-proj expansion into 
class/c-proj instead of compose-class.

svn: r18235
 2010-02-20 22:00:45 +00:00
Stevie Strickland
66ce493ede Adding original class field (we'll see what this is for in a sec.) 
svn: r18234
 2010-02-20 21:48:00 +00:00
Stevie Strickland
a0fdeff509 First order checks. 
svn: r18233
 2010-02-20 21:34:57 +00:00
Stevie Strickland
a4d6252d16 Start inherit contracts (which are useful for mixins). Tests, plus parsing. 
svn: r18232
 2010-02-20 21:28:20 +00:00
Stevie Strickland
cd4aa4c6f6 Forgot about the no-contract forms, so needed to add tests for those, also. 
svn: r18218
 2010-02-20 10:40:50 +00:00
Stevie Strickland
7830d55b42 Okay, that does it for augment, which means I'm done with coding. Now just 
documentation and benchmarking, then this can go on trunk.

svn: r18217
 2010-02-20 10:09:37 +00:00
Stevie Strickland
67d47e0a1d Fixes in override ctcs and test suite. I thought I ran it, so I find it 
weird that I found these on a subsequent run when adding some quick augment
tests to start the next batch.  (Oh, those are included also.)

svn: r18215
 2010-02-20 09:40:41 +00:00
Stevie Strickland
b5e2d5f93e Okay, now override contracts are done, so only augments remain. 
svn: r18214
 2010-02-20 09:30:40 +00:00
Stevie Strickland
3c1004fd05 Okay, we should be fixed up in compose-class, now we just need to start 
handling the projections in class/c-proj.

svn: r18213
 2010-02-20 09:14:14 +00:00
Stevie Strickland
28046b832b Another step towards it -- here we're extending the int-methods vector 
appropriately on subclassing after a contract boundary.  Next is adding
in the projections.

svn: r18211
 2010-02-20 08:43:54 +00:00
Stevie Strickland
a7017afe5a Step 1: Cut a ... 
Wait, no.  Here we add the dynamic idxs, which will get incremented whenever
we pass through a contract boundary with an override (or later, augment)
contract.

svn: r18210
 2010-02-20 08:21:09 +00:00
Stevie Strickland
90d8d3763a Forgot to put this here. 
svn: r18208
 2010-02-20 06:36:28 +00:00
Stevie Strickland
ead01c9232 There's an app... err, function for that. 
svn: r18207
 2010-02-20 05:32:13 +00:00
Stevie Strickland
98e3695a20 Also change some old code to use vector-copy! as appropriate. 
svn: r18206
 2010-02-20 05:25:36 +00:00
Stevie Strickland
7b7d70a993 I should just use vector-copy! where applicable. 
svn: r18205
 2010-02-20 05:20:15 +00:00
Stevie Strickland
aaf9a5aeac Apply the inherit-field projections appropriately. 
svn: r18204
 2010-02-20 04:18:49 +00:00
Stevie Strickland
fcee6788d7 Parsing and first order checks for internal field access contracts. 
svn: r18203
 2010-02-20 04:02:59 +00:00
Stevie Strickland
d87794a8d2 External field contracts FTW! 
svn: r18202
 2010-02-20 03:52:47 +00:00
Stevie Strickland
1688a6c3f7 Change how fields are accessed in prep for contract wrapping. 
svn: r18201
 2010-02-20 01:35:46 +00:00
Stevie Strickland
30864fc1d0 I dunno why, but this reads much better to me. 
svn: r18200
 2010-02-20 00:08:49 +00:00
Stevie Strickland
95438db40f Add set-field!. Because it's useful, because we have get-field, so why 
not it, and because it's an easy way to later test external field contracts.

svn: r18199
 2010-02-19 23:55:39 +00:00
Stevie Strickland
6777fc31a3 Rewrite this a little to make it clear that we're now only checking the 
super class's beta-methods vector to make sure this is even an overrideable
method.

svn: r18181
 2010-02-19 04:59:05 +00:00
Stevie Strickland
55d39b0035 It was a good thing I decided to add some super/inner mixed examples here, 
because it pointed out a bug in my implementation where we weren't getting
the right version of the super method (which gets the projection).

svn: r18180
 2010-02-19 04:40:10 +00:00
Stevie Strickland
5cc68fdd0f In some ways, I'm still trying to decide exactly what some of these forms mean. 
For example, if we're in the java part of a beta-java chain, can we still add
an inner contract?  If so, it should affect each java-style overriding method
until we reach the next beta-style augmenting method.

It can just be confusing, because one might thing that inner in a
contract => needs an augmenting method in the subclass, super => needs
an overriding method in the subclass.  The latter is true, since only
the next immediate method can reach the super class's implementation,
but inner jumps to the next augmenting method, so the former isn't
necessarily true.

svn: r18179
 2010-02-19 04:27:44 +00:00
Stevie Strickland
b59955bc01 Ah, that'd be the issue. THE TESTS WERE WRONG. All's well, and I've even 
added a couple more tests to make sure we apply the projections in the right
order.

svn: r18176
 2010-02-19 00:34:27 +00:00
Stevie Strickland
2b92ea9225 Start inner projections work. Next, test cases, then I'll fix the test 
cases by implementing the rest.

svn: r18174
 2010-02-18 23:54:56 +00:00
Stevie Strickland
da7473b867 TEST DRIVEN DEVELOPMENT. 
svn: r18173
 2010-02-18 23:35:58 +00:00
Stevie Strickland
301ac0e5f3 The simplest of all the contract features to handle. 
svn: r18169
 2010-02-18 23:17:48 +00:00
Stevie Strickland
cc52bcd197 Start throwing in higher-order checks. 
svn: r18168
 2010-02-18 23:09:42 +00:00
Stevie Strickland
ce04db35a0 Rename tests to be more specific, start inner tests, fix introduced bug. 
svn: r18164
 2010-02-18 22:27:34 +00:00
Stevie Strickland
a7d8507e3c Actually, these have slightly different conditions. super contracts require 
an overrideable method (augride is okay), whereas override contracts require
a method which has never been augmentable (i.e. no pubments or overments).

svn: r18162
 2010-02-18 22:11:01 +00:00