Demonstration venue · read-only. Every page can be browsed; the buttons that would change it are switched off. Create an account to run TaxoReview on your own data.

Clyde Ruby

dblp:34/4598 · DBLP profile ↗
← Back
2ranked-venue papers
1as first author
0since 2021 · last 2005
—ORCID · none

Domains — the database's venue-derived domains; a paper can count in several

Software engineering, systems software and programming languages · 2 · 1 first-author

Expertise — from the expertise taxonomy: the topics of the expert's papers under the CCF categories. A weight counts papers with recency: 1 for a paper about the topic, 0.3 when the topic is its context, halved every five years.

Software engineering, system software, and programming languages
1 paper
Programming languages and type systems · 100%

Topics — the 3 heaviest of 3, each with the papers that count most for it

TopicWeightPapersLastEvidence papers
Programming languages and type systems
specification language
0.012000
Safely creating correct subclasses without seeing superclass code · OOPSLA 2000
Programming languages and type systems › inheritance
subclassing
0.012000
Safely creating correct subclasses without seeing superclass code · OOPSLA 2000
Programming languages and type systems › type systems
subtyping
0.012000
Safely creating correct subclasses without seeing superclass code · OOPSLA 2000

Methods — techniques the papers use, named apart from their topics

reasoning technique · 0.0formal specification · 0.0
YearPublicationVenuePosition
2005 How the design of JML accommodates both runtime assertion checking and formal verification
Gary T. Leavens, Yoonsik Cheon, Curtis Clifton, Clyde Ruby, David R. Cok
Sci. Comput. Program.4
2000 Safely creating correct subclasses without seeing superclass code
abstract
A major problem for object-oriented frameworks and class libraries is how to provide enough information about a superclass, so programmers can safely create new subclasses without giving away the superclass's code. Code inherited from the superclass can call down to methods of the subclass, which may cause nontermination or unexpected behavior. We describe a reasoning technique that allows programmers, who have no access to the code of the superclass, to determine both how to safely override the superclass's methods and when it is safe to call them. The technique consists of a set of rules and some new forms of specification. Part of the specification would be generated automatically by a tool, a prototype of which is planned for the formal specification language JML. We give an example to show the kinds of problems caused by method overrides and how our technique can be used to avoid them. We also argue why the technique is sound and give guidelines for library providers and programmer...
Clyde Ruby, Gary T. Leavens
OOPSLA1