Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

eiffeldoc fails due to tutorial class/generic argument name conflict ITEM #114

Closed
ramack opened this Issue May 28, 2013 · 5 comments

Comments

Projects
None yet
3 participants
Owner

ramack commented May 28, 2013

since I added the tutorial classes to the loadpath, class ITERATOR_ON_C_ARRAY [ITEM->C_STRUCT] fails to compile, because ITEM is ambiguous.
What shall we do?

  1. remove the tutorial classes from the global loadpath again
  2. rename the generic name ITEM?
  3. make the compile error a warning
  4. any other idea?

Independent from this decision I tend to copy the class which was the reason to add the tutorial load path into the tests. I think it is much cleaner to have the tests and tutorial independent...

Owner

cadrian commented May 29, 2013

In SmartEiffel the convention for generic classes is a class name with a trailing underscore. Therefore ITEM should be renamed ITEM_ or even better E_.

There were discussions to enforce that in the compiler; we could still add parser rules to at least generate a warning when the generic class name does not follow the convention.

Owner

cadrian commented May 29, 2013

I don't see why the tests could not depend on the tutorial. After all, the tutorial classes are useful for the final user; they could be tested too.

@ghost ghost assigned cadrian May 29, 2013

Owner

tybor commented May 29, 2013

2013/5/29 Cyril Adrian notifications@github.com

In SmartEiffel the convention for generic classes is a class name with a
trailing underscore. Therefore ITEM should be renamed ITEM_ or even
better E_.

You are right. Yet I defend at least the rationale behind this unlucky name
choice: in my ideal world Eiffel code should almost read like the English
language from which it borrows its reserved words. Any non-literal,
expecially at the end or at the beginning of a word brings in the risk of
making code far less understandable to the reader which has to focus to see
if the white space just after the word hosts an underscore.
I would rather propose another convention, akin to the one I already
proposed for argument placeholder: prefixing the generic class name with an
indefinite article, so as I often write "a_window: GTK_WINDOW" or
"an_object: G_OBJECT" we may give the generic classes names like AN_ITEM,
or A_WIDGET and so on.
I know I may look stubborn with my obsession with literate programming, but
I'm convinced that one of the selling point of Eiffel is its readability
and its similarity with hypotetical simplified English language, making our
beloved language one of the fittest to be used as a Literate Programming
tool.

Meanwhile I'll fix it ASAP...

@ghost ghost assigned tybor May 29, 2013

Owner

cadrian commented May 29, 2013

OK, I leave it to you then.

@cadrian cadrian referenced this issue May 29, 2013

Closed

alleviate VCFG #115

Owner

tybor commented May 29, 2013

Today I've been quite busy with sands and experimental concretes...
tonight, after the choir practice I'll deal with it: the repository I got
here at work is far too messed up to handle this issue quickly and cleanly.

Waiting to now your opinion on my proposal for naming convention I'll stick
to the trailing underscore style guide.

I cannot help but notice that this convention reminds me of the ugly
symbols I found deeply buried in the standard C headers, those that meddle
with lowest level possible, just above assembler. Most of these have 2 or
even 3 prefix underscores: see for example __need_NULL in my stdlib.h
Please forget my rants as they are those of a plaintive guy who spent some
time jumping up and down in the lower strata of gcc and llvm headers... 8-P

2013/5/29 Cyril Adrian notifications@github.com

OK, I leave it to you then.


Reply to this email directly or view it on GitHubhttps://github.com/LibertyEiffel/Liberty/issues/114#issuecomment-18619455
.

@tybor tybor closed this in 725bf9e May 30, 2013

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment