Skip to content

Commit

Permalink
Add a superclass test.
Browse files Browse the repository at this point in the history
  • Loading branch information
ltratt committed Jun 16, 2020
1 parent 0263235 commit 89bc1de
Show file tree
Hide file tree
Showing 2 changed files with 19 additions and 0 deletions.
14 changes: 14 additions & 0 deletions lang_tests/inst_var_at_put_superclass/test.som
Original file line number Diff line number Diff line change
@@ -0,0 +1,14 @@
"
VM:
status: success
stdout: 2
"

test = test_super (
| x |

run = (
self instVarAt: 1 put: 2.
self f.
)
)
5 changes: 5 additions & 0 deletions lang_tests/inst_var_at_put_superclass/test_super.som
Original file line number Diff line number Diff line change
@@ -0,0 +1,5 @@
test_super = (
f = (
(self instVarAt: 1) println.
)
)

9 comments on commit 89bc1de

@smarr
Copy link
Contributor

@smarr smarr commented on 89bc1de Jun 16, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's not really what I had in mind. I would have expected the super class to have a field too, to test for the expected ordering between fields of super and sub classes.

@ltratt
Copy link
Member Author

@ltratt ltratt commented on 89bc1de Jun 16, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I did briefly try that, but I don't think one can/should rely on the ordering, so there's no way to work out what name maps to what index.

@smarr
Copy link
Contributor

@smarr smarr commented on 89bc1de Jun 16, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There's an assumption that the fields of the super class come before the fields of the subclass.
And for the instVarAt:* accessing, the indexes should be determine by lexical order, otherwise, this wouldn't be a very useful API.

@ltratt
Copy link
Member Author

@ltratt ltratt commented on 89bc1de Jun 16, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Those are assumptions too far for me! [As that suggests, I think the API is not well designed, because it exposes pointless details. But that's language design!]

@smarr
Copy link
Contributor

@smarr smarr commented on 89bc1de Jun 16, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, let me rephrase: It's not an assumption, it's a specification.

@smarr
Copy link
Contributor

@smarr smarr commented on 89bc1de Jun 16, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

And, no, it doesn't expose any implementation details. It only does so if you wish to align your implementation to these requirements.

@ltratt
Copy link
Member Author

@ltratt ltratt commented on 89bc1de Jun 16, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Dumb question: where are such details written down and codified? Because I know I'll forget this detail in about 2 days time!

@smarr
Copy link
Contributor

@smarr smarr commented on 89bc1de Jun 16, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@smarr
Copy link
Contributor

@smarr smarr commented on 89bc1de Jun 16, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The origin of this API is class Smalltalk systems, where it indeed is a direct reflection of the implementation: http://www.mirandabanda.org/bluebook/bluebook_chapter29.html#StorageManagementPrimitives29
But it does not have to be that way.

Please sign in to comment.