Home Comments

Putting ICE implementation files in a separate package

vsonnathivsonnathi Member Venkat RamanaOrganization: Amazon.comProject: Prototype ✭✭

Slice2Java generates a lot of files, can we put some of the files not directly used by either Client or Server into a iceimpl package?

For e.g:

module print {
class Data {
string name;
int number;

interface Printer {
void printString(Data s);

Generates the following files:

Can we move all the _*.java files into com\testing\print\iceimpl package? This way it makes source tree more readable and which one to look at and which ones to leave out.



  • mesmes CaliforniaAdministrators, ZeroC Staff Mark SpruiellOrganization: ZeroC, Inc.Project: Ice Developer ZeroC Staff
    Hi Venkat,

    We recommend that you do something similar to what we've done in the Ice for Java sources, namely that the generated code be placed in a separate directory. There are a couple of advantages in doing this:

    1. You don't have to sift through all of the generated files to find the ones you've written.

    2. It's much safer (and easier) when you want to recompile all your Slice files if you can simply remove the directory containing the generated code without worrying about accidentally removing your implementation files.

    Take care,
    - Mark
  • vsonnathivsonnathi Member Venkat RamanaOrganization: Amazon.comProject: Prototype ✭✭

    Thanks for the response. Yes, it is a good idea to separate the files written by me from the ones generated by ICE. What I would like to see is some of the core implementation files _*.java generated by ICE (As per documentation: These files contain code that is internal to the Java mapping; they do not contain any functions of relevance to application programmers.) to be moved into a separate iceimpl sub package with in the main package.

    When constructing we need to browse through the Class generated by ICE especially the ones for Classes.

    It would be nice if there is an option to generate the toString method to print the member variables of a given class as this would aid in debugging.

    Also, it would be nice to have getter and setter methods for member variables for Classes instead of directly exposing data members (Basic OO - encapsulation).

  • michimichi Member Michi HenningOrganization: Triodia TechnologiesProject: I have a passing interest in Ice :-) ✭✭✭
    Of the generated classes, only the *Del, *DelM, and *DelD classes are mapping-internal. The remainder is exposed to application code. So, putting these into a separate package would probably not achieve all that much (and would make it somewhat more complex to generate the code). As Mark suggested, I would simply use the --output-dir option for slice2java to put the generated code into a separate directory.

    As for the toString() suggestion, we'll have a look at this. It's a trade-off between convenience and the generated code size, so I'm not quite sure yet if we should do this. We'll give it serious thought though.


  • vsonnathivsonnathi Member Venkat RamanaOrganization: Amazon.comProject: Prototype ✭✭
    Hi Michi,

    Thanks for your response.

    Regarding the toString, enable it only when somebody specifies some kind of metadata for a given class. By default it can be off.

Sign In or Register to comment.