Eiffel Loop's EL_PLAIN_TEXT_FILE and ARGUMENTS_32 feature name clashes (WMFN error code)

[Hank Lenzi]

Hi all --

In trying to use Eiffel Loop's EL_PLAIN_TEXT_FILE, in my code, I used the following:

In my APPLICATION class I have:

class
 APPLICATION


inherit
 ARGUMENTS_32
 EL_PLAIN_TEXT_FILE

Now the EiffelStudio compiler gives me this error:

Error code: VMFN

Error: two or more features have same name.

What to do: if they must indeed be different features, choose different

  names or use renaming; if not, arrange for a join (between deferred

  features), an effecting (of deferred by effective), or a redefinition. 

Class: APPLICATION

Feature: new_cursor: ITERATION_CURSOR [IMMUTABLE_STRING_32] inherited from: ARGUMENTS_32 Version from: ARGUMENTS_32

Feature: new_cursor: FILE_ITERATION_CURSOR inherited from: EL_PLAIN_TEXT_FILE Version from: FILE

So, I'm thinking of taking a bold step and just leaving ARGUMENTS_32 out. 

Would that be OK?

TIA

-- Hank

[Germán Arias]

If you want make a program (command line program) which read and write a file, you don't need inherit from EL_PLAIN_TEXT_FILE. Just add an attribute and work with it. Something like:

my_file: EL_PLAIN_TEXT_FILE

Germán

--
You received this message because you are subscribed to the Google Groups "Eiffel Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to eiffel-users...@googlegroups.com.
Visit this group at https://groups.google.com/group/eiffel-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/eiffel-users/7fb2abcf-a861-43b5-8a56-25105b0dd6d5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Alexander Kogtenkov]

I guess, you started from a new basic project where ARGUMENTS_32 was added to the root class automatically. It is there for convenience, if you would like to read command-line arguments passed to the program. There is no requirement to keep this inheritance link. Moreover, with introduction of class features, the inheritance link is not needed to call features of this class. The only difference would be that instead of

   argument (3)

the code would be slightly more verbose:

   {ARGUMENTS_32}.argument (3)

In other words, it is safe to exclude ARGUMENTS_32 from the list of parents.

As to inheritance from EL_PLAIN_TEXT_FILE, as pointed out in another answer to your question, it's better to use client relationship, because your application is not a file, but rather a client of a file.

Regards,
Alexander Kogtenkov

Hank Lenzi <hank....@gmail.com>:

[Finnian Reilly]

Class: APPLICATION

Feature: new_cursor: ITERATION_CURSOR [IMMUTABLE_STRING_32] inherited from: ARGUMENTS_32 Version from: ARGUMENTS_32

Feature: new_cursor: FILE_ITERATION_CURSOR inherited from: EL_PLAIN_TEXT_FILE Version from: FILE

So, I'm thinking of taking a bold step and just leaving ARGUMENTS_32 out. 

Since you are already using Eiffel-Loop, may I suggest using the class EL_MODULE_ARGS from base.ecf, which gives you access to all the routines in ARGUMENTS_32 via the shared instance Args. By inheriting EL_MODULE_ARGS you are less likely to encounter name clashes as there is only one feature in the class. In addition you also get some additional convenience routines defined by class EL_COMMAND_LINE_ARGUMENTS which inherits ARGUMENTS_32.

Eiffel-Loop also has an advanced way of mapping command line arguments to the arguments of a make routine of a class that inherits EL_COMMAND

Take for example the utility app CHECK_LOCALE_STRINGS_APP which verifies localization strings in a source base. The app class maps command arguments on the arguments of the make routine in class CHECK_LOCALE_STRINGS_COMMAND.

What you get for free is help messages if you invoke the application with -help, and also error message if for example you do not supply a required arguments as for example `config'. It also does type conversions between command argument strings and numeric or boolean arguments in the make routine.

class
   CHECK_LOCALE_STRINGS_APP

inherit
   EL_LOGGED_COMMAND_LINE_SUB_APPLICATION [CHECK_LOCALE_STRINGS_COMMAND]
      redefine
         Option_name
      end

create
   make

feature {NONE} -- Implementation

   argument_specs: ARRAY [like specs.item]
      do
         Result := <<
            valid_required_argument ("config", "Configuration file path", << file_must_exist >>),
            optional_argument ("language", "Language code to check")
         >>
      end

   default_make: PROCEDURE
      do
         Result := agent {like command}.make ("", "en")
      end

feature {NONE} -- Constants

   Option_name: STRING = "check_locale_strings"

   Description: STRING = "Check that every locale string can be found in given locale"

   Log_filter: ARRAY [like CLASS_ROUTINES]
         --
      do
         Result := <<
            [{CHECK_LOCALE_STRINGS_APP}, All_routines]
         >>
      end

end

If you don't wish to have logging in your application you can inherit from EL_COMMAND_LINE_SUB_APPLICATION instead of EL_LOGGED_COMMAND_LINE_SUB_APPLICATION

 

[Hank Lenzi]

Interesting. 

[Hank Lenzi]

I see. A bit of conceptual errors on my part (new to OOP).