The Experts below are selected from a list of 165 Experts worldwide ranked by ideXlab platform
Christopher Seguin - One of the best experts on this subject based on the ideXlab platform.
-
refactoring tool challenges in a Strongly Typed Language poster session
Conference on Object-Oriented Programming Systems Languages and Applications, 2000Co-Authors: Christopher SeguinAbstract:This poster examines the challenges of developing a refactoring tool for a weakly Typed Language such as Smalltalk as opposed to a Strongly Typed Language such as Java. To explore this, we will compare the push up field refactoring in each Language. This refactoring was selected because it is relatively simple conceptually, but difficult to implement for Java. In a weakly Typed Language such as Smalltalk, push up field is simple. The user simply determines that the parent class needs the variable. The refactoring tool moves the field to the parent class. Then the tool searches all the subclasses of the parent class, if the classes have a variable with the same name, the refactoring tool removes the variable from the subclass. The task is complete. For Java, a description of classes and types is necessary. Let's start with a base class A. A has a number of child classes, B, C, D, E, F, and G. Each of B-G has a single instance variable named var. The only difference between the classes is the type of var. B and C both have a variable named var with type X. D has a variable named var with a type Y. E has a variable named var with type W. F has a variable named var with a type of Z. And G has a variable named var with the type int. W, X, Y, and Z are classes. W is the base class, X is a subclass of W, and Y is a subclass of X. Z is unrelated to all of the other classes. Since all subclasses of A have a variable named var, a programmer might suspect that they could reduce the amount of code by moving the variable into the parent class A. Let's move the field named var from class B into class A. Like in Smalltalk, the Java refactoring tool can remove the variable var from B and C, since the var variable in both classes have the same type. The source file for A would get the declaration of type X named var. The source file for A might also gain an import for the type X. Let's postpone the discussion of the scope of the variable var. The refactoring tool can remove var from D since the storage in A is sufficient. However, the impact on the source code depends on whether there is a difference between the interface of X and Y. If there are methods or fields added in Y that are not in X, then by removing the variable var from D, the refactoring tool must be sure to cast var back to a Y in code that refers to var in a way that accesses the differences. For instance, if X and Y have a method m, then in D the invocation var.m() remains unchanged. If Y has a method n and no similar method is present in X or a parent class of X, then D must change the code that looks like var.n(); to ((Y) var).n(); The refactoring tool cannot remove var from E, since a variable of type W can not be stored in a class X. A refactoring tool might change the type of the object in class A to W. The effect of casting var to an X or a Y type would be more widespread. To remove var from F, the refactoring tool would need to change the variable var's type to Object, since Object is the base class for all classes thus would be a common storage type for Ws and Zs. Everywhere that var is used in any source files, it must be cast to the appropriate type, eliminating the benefit of compile time type checking. Removing var from G is even more difficult, since a primitive type such as int does not derive from Object, the refactoring tool must find a way to store var for G. Java provides a series of immutable types that store the primitive types, i.e. java.lang.Integer. To access the variable's value, “var” would be replaced with “var.intValue()”. To set var, the tool would create a new instance of the Integer class, and assign it to var. Since multithreaded programming is encouraged, any operation that replaces an atomic action with a series of steps must be considered very carefully. In this instance, the assignment of a value to var is atomic, but now includes the creation of an Integer object followed by an assignment. Object instantiation is not atomic, therefore if might be necessary to wrap the assignment of var in an appropriate synchronized block. Synchronized blocks are computationally very expensive, and should not be used indiscriminately. Therefore, an automated tool should not remove the variable var from G as a result of pushing var from B to A Instead, a refactoring tool might recommend renaming the variable var in G.
-
OOPSLA Addendum - Refactoring tool challenges in a Strongly Typed Language (poster session)
Addendum to the 2000 proceedings of the conference on Object-oriented programming systems languages and applications (Addendum) - OOPSLA '00, 2000Co-Authors: Christopher SeguinAbstract:This poster examines the challenges of developing a refactoring tool for a weakly Typed Language such as Smalltalk as opposed to a Strongly Typed Language such as Java. To explore this, we will compare the push up field refactoring in each Language. This refactoring was selected because it is relatively simple conceptually, but difficult to implement for Java. In a weakly Typed Language such as Smalltalk, push up field is simple. The user simply determines that the parent class needs the variable. The refactoring tool moves the field to the parent class. Then the tool searches all the subclasses of the parent class, if the classes have a variable with the same name, the refactoring tool removes the variable from the subclass. The task is complete. For Java, a description of classes and types is necessary. Let's start with a base class A. A has a number of child classes, B, C, D, E, F, and G. Each of B-G has a single instance variable named var. The only difference between the classes is the type of var. B and C both have a variable named var with type X. D has a variable named var with a type Y. E has a variable named var with type W. F has a variable named var with a type of Z. And G has a variable named var with the type int. W, X, Y, and Z are classes. W is the base class, X is a subclass of W, and Y is a subclass of X. Z is unrelated to all of the other classes. Since all subclasses of A have a variable named var, a programmer might suspect that they could reduce the amount of code by moving the variable into the parent class A. Let's move the field named var from class B into class A. Like in Smalltalk, the Java refactoring tool can remove the variable var from B and C, since the var variable in both classes have the same type. The source file for A would get the declaration of type X named var. The source file for A might also gain an import for the type X. Let's postpone the discussion of the scope of the variable var. The refactoring tool can remove var from D since the storage in A is sufficient. However, the impact on the source code depends on whether there is a difference between the interface of X and Y. If there are methods or fields added in Y that are not in X, then by removing the variable var from D, the refactoring tool must be sure to cast var back to a Y in code that refers to var in a way that accesses the differences. For instance, if X and Y have a method m, then in D the invocation var.m() remains unchanged. If Y has a method n and no similar method is present in X or a parent class of X, then D must change the code that looks like var.n(); to ((Y) var).n(); The refactoring tool cannot remove var from E, since a variable of type W can not be stored in a class X. A refactoring tool might change the type of the object in class A to W. The effect of casting var to an X or a Y type would be more widespread. To remove var from F, the refactoring tool would need to change the variable var's type to Object, since Object is the base class for all classes thus would be a common storage type for Ws and Zs. Everywhere that var is used in any source files, it must be cast to the appropriate type, eliminating the benefit of compile time type checking. Removing var from G is even more difficult, since a primitive type such as int does not derive from Object, the refactoring tool must find a way to store var for G. Java provides a series of immutable types that store the primitive types, i.e. java.lang.Integer. To access the variable's value, “var” would be replaced with “var.intValue()”. To set var, the tool would create a new instance of the Integer class, and assign it to var. Since multithreaded programming is encouraged, any operation that replaces an atomic action with a series of steps must be considered very carefully. In this instance, the assignment of a value to var is atomic, but now includes the creation of an Integer object followed by an assignment. Object instantiation is not atomic, therefore if might be necessary to wrap the assignment of var in an appropriate synchronized block. Synchronized blocks are computationally very expensive, and should not be used indiscriminately. Therefore, an automated tool should not remove the variable var from G as a result of pushing var from B to A Instead, a refactoring tool might recommend renaming the variable var in G.
R. Plasmeijer - One of the best experts on this subject based on the ideXlab platform.
-
The implementation of interactive local state transition systems in clean
Lecture Notes in Computer Science, 2000Co-Authors: Peter Achten, R. PlasmeijerAbstract:The functional programming Language Clean offers an extensive library, the object I/O library, to programmers to create interactive applications that use Graphical User Interfaces (GUI). Programs are constructed by composition of interactive objects. Interactive objects share state. To support modular programming it is also possible to provide objects with local state. Hierarchies of stateful objects are defined by means of algebraic specifications. Good use is made of the fact that Clean is a Strongly Typed Language. In this paper we show how the evaluation of interactive objects is implemented in the object I/O library. The evaluation can be handled elegantly using lazy evaluation.
Peter Achten - One of the best experts on this subject based on the ideXlab platform.
-
The implementation of interactive local state transition systems in clean
Lecture Notes in Computer Science, 2000Co-Authors: Peter Achten, R. PlasmeijerAbstract:The functional programming Language Clean offers an extensive library, the object I/O library, to programmers to create interactive applications that use Graphical User Interfaces (GUI). Programs are constructed by composition of interactive objects. Interactive objects share state. To support modular programming it is also possible to provide objects with local state. Hierarchies of stateful objects are defined by means of algebraic specifications. Good use is made of the fact that Clean is a Strongly Typed Language. In this paper we show how the evaluation of interactive objects is implemented in the object I/O library. The evaluation can be handled elegantly using lazy evaluation.
-
IFL - The Implementation of Interactive Local State Transition Systems in Clean
Implementation of Functional Languages, 2000Co-Authors: Peter Achten, Marinus J. PlasmeijerAbstract:The functional programming Language Clean offers an extensive library, the object I/O library, to programmers to create interactive applications that use Graphical User Interfaces (GUI). Programs are constructed by composition of interactive objects. Interactive objects share state. To support modular programming it is also possible to provide objects with local state. Hierarchies of stateful objects are defined by means of algebraic specifications. Good use is made of the fact that Clean is a Strongly Typed Language. In this paper we show how the evaluation of interactive objects is implemented in the object I/O library. The evaluation can be handled elegantly using lazy evaluation.
A.a. Radenski - One of the best experts on this subject based on the ideXlab platform.
-
Parallel object-oriented programming with multiple inheritance: Language design issues
Proceedings 1st International Conference on Algorithms and Architectures for Parallel Processing, 1Co-Authors: A.a. RadenskiAbstract:The transition from sequential object-oriented programming (OOP) to parallelism has been in the focus of active research. Experimental Languages that try to integrate objects and parallelism are often seriously compromised in their capability to provide inheritance for parallel objects. Even Languages that permit some amalgamation of parallelism and inheritance tend to support only single-class inheritance. The purpose of this paper is to specify a Strongly Typed Language framework for parallel object-oriented programming which provides easy-to-use multiple inheritance for parallel objects, including inheritance for synchronization code. The proposed approach to parallelism is based on "separate" methods which generate processes and provide rendezvous-type coordination: it succeeds in cases where known Languages fail to combine inheritance with parallelism. Or do it inefficiently and inconveniently. >
Kenneth L. Calvert - One of the best experts on this subject based on the ideXlab platform.
-
Chapter 3 – Sending and Receiving Data
TCP IP Sockets in Java, 2008Co-Authors: Kenneth L. CalvertAbstract:Publisher Summary Any programs that exchange information must agree on how that information will be encoded—represented as a sequence of bits—as well as which program sends what information when, and how the information received affects the behavior of the program. This chapter discusses sending and receiving data. It discusses how simple values such as ints, longs, chars, and Strings can be sent and received via sockets. The TCP/IP protocols transport bytes of user data without examining or modifying them. This allows applications great flexibility in how they encode their information for transmission. Most application protocols are defined in terms of discrete messages made up of sequences of fields. Each field contains a specific piece of information encoded as a sequence of bits. The application protocol specifies exactly how these sequences of bits are to be arranged by the sender and interpreted, or parsed, by the receiver so that the latter can extract the meaning of each field. Bytes of information can be transmitted through a socket by writing them to an OutputStream (associated with a Socket) or encapsulating them in a DatagramPacket (which is then sent via a DatagramSocket). However, the only data types to which these operations can be applied are bytes and arrays of bytes. As a Strongly Typed Language, Java requires that other types—int, String, and so on—be explicitly converted to byte arrays. Fortunately, the Language has built-in facilities to help with such conversions.
-
Sending and Receiving Messages
TCP IP Sockets in C#, 2004Co-Authors: David Makofske, Michael J. Donahoo, Kenneth L. CalvertAbstract:This chapter covers the basics of message construction and parsing. The TCP/IP protocols transport bytes of user data without examining or modifying them. This allows applications great flexibility in how they encode their information for transmission. For various reasons, most application protocols are defined in terms of discrete messages made up of sequences of fields. Each field contains a specific piece of information encoded as a sequence of bits. The application protocol specifies how these sequences of bits are to be formatted by the sender and interpreted, or parsed, by the receiver so that the latter can extract the meaning of each field. About the only constraint imposed by TCP/IP is that information must be sent and received in chunks whose length in bits is a multiple of eight. As a Strongly Typed Language, Java requires that other types―String, int, and so on―be explicitly converted to these transmittable types. Fortunately, the Language has a number of built-in facilities that make such conversions more convenient. It is explored how Java data types can be encoded in different ways, and how messages can be constructed from various types of information. Recent versions of Java include serialization capabilities―the Serializable and Externalizable interfaces—which provide for instances of supporting Java classes to be converted to and from byte sequences very easily. A basic tenet of good protocol design is that the protocol should constrain the implementor as little as possible and should minimize assumptions about the platform on which the protocol will be implemented.
-
Chapter 3 – Sending and Receiving Messages
TCP IP Sockets in Java, 2002Co-Authors: Kenneth L. CalvertAbstract:Publisher Summary This chapter covers the basics of message construction and parsing. The TCP/IP protocols transport bytes of user data without examining or modifying them. This allows applications great flexibility in how they encode their information for transmission. For various reasons, most application protocols are defined in terms of discrete messages made up of sequences of fields. Each field contains a specific piece of information encoded as a sequence of bits. The application protocol specifies how these sequences of bits are to be formatted by the sender and interpreted, or parsed, by the receiver so that the latter can extract the meaning of each field. About the only constraint imposed by TCP/IP is that information must be sent and received in chunks whose length in bits is a multiple of eight. As a Strongly Typed Language, Java requires that other types―String, int, and so on―be explicitly converted to these transmittable types. Fortunately, the Language has a number of built-in facilities that make such conversions more convenient. It is explored how Java data types can be encoded in different ways, and how messages can be constructed from various types of information. Recent versions of Java include serialization capabilities―the Serializable and Externalizable interfaces—which provide for instances of supporting Java classes to be converted to and from byte sequences very easily. A basic tenet of good protocol design is that the protocol should constrain the implementor as little as possible and should minimize assumptions about the platform on which the protocol will be implemented.
