[Gambas-user] Suggestions 4 new keywords

[Doriano Blengino]

Fabián Flores Vadell ha scritto:
> 2010/9/16 Doriano Blengino <doriano.blengino at ...1909...>:
>   
>> Ok, I will argue about it. From what I understand, the paradigm you
>> describe looks similar to pascal (and C++): an interface section
>> declares all the public symbols, which will be detailed (implemented)
>> later. So every method declaration must be written twice, in interface
>> and in implementation. And this alone is a lot of typing. When the
>> number of lines between interface and implementation grows to several
>> screens, you start to navigate up and down in the source. A good
>> editor/IDE can help, but the problem remains: why we have to write the
>> same things twice? Perhaps because a compiler born in the '70 could not
>> read the same source twice, especially if that source was punched on
>> cards... it is no surprise that a pascal compiler, on modern computers,
>> is so fast: the program is written in a way totally good for the compiler!
>>
>> So, I prefer the gambas way - you write things once, exactly where you
>> want, and the compiler does the rest.
>>     
>
> Ok. Now I can understand you.
>
> You mistakenly thought than I meant that "INTERFACE" and
> "IMPLEMENTATION" keywords should work as they do in Pascal. But I'm
> don't saying that. Nothing about that there's in the example I wrote.
>
> There's no need to double typing.
>   
Ok, sorry. Perhaps this is because my habits. From my experience, 
"Interface" means a declaration without any implementation (call it 
prototype, if you want), and "Implementation" means something that is 
hidden (private, if you want). But, now, it's your turn to 
argue/demonstrate: what languages use interface and implementation in 
the way you intend? I am always very interested in any new language I 
don't know! But beware: if only pascal has that two keywords, then I am 
right, and you are wrong, and by your own words! :-) If so, in fact, you 
wanted to use interface and implementation in their wrong meaning - the 
right keywords for you would be public and private (and protected, 
published, and so on): it's you (and I agree) that says that words are 
important...

>   
>> You say that your proposal is only an <<alternative>>. Ok. Even an
>> alternative, an option, must respond to good criteria. I am not saying
>> that your proposal is wrong - simply I think that probably it is not
>> what a gambas user expects. To let you know, I am probably the most
>> critic user of gambas - I am not afraid to point out its weaknesses. But
>> this time, I think that gambas is right.
>>     
>
> You are doing a wrong reasoning.
>
> Whatever that user expects is cover by the current syntax. Any new
> thing (about syntax), will be unexpected to users and possibly will be
> very different from BASIC.
>
> Many examples about that there's in Gambas. Think about a little and
> you will find many cases.
>   
This point is true, and I am wrong again. I must reformulate my thought. 
"What a user expects" is a restricted way to say "what a language should 
be". Should a language be a chameleon? If it aims to be basic (modern 
basic, but still basic), then it should not borrow too much from other 
paradigms which nothing have in common with basic. And please note I 
wrote "not borrow too much" - I don't intend to be too rigid.

>   
>>> A very important advantage, was not emphasized enough: keywords closer
>>> to OOP help very much to teaching an OOP language, because them are
>>> closely related to the OOP concepts.
>>>
>>>       
>> Uhm... I don't understand why interface and implementation should be
>> related in any way to OOP. Don't forget that the gambas way of having
>> form=class=module/unit/library/whatever=file is a gambas specific
>> simplification. More mature languages can declare more than one class in
>> a file, or use more files to declare a single class. Interface and
>> implementation existed before OOP was invented, and OOP can live without
>> them; these two keywords are simply a way to group declarations - be
>> them OOP declarations or not.
>>     
>
> I never said that INTERFACE and IMPLEMENTATION concepts are exclusive
> from OOP. But in OOP these concepts are a fundamental consequence of
> encapsulation.
>   
I don't understand well. But I can repeat that public and private refer 
to encapsulation (well, not really true), like interface and 
implementation. But encapsulation is not exclusive to OOP. So, I don't 
understand why interface/implementation should "be closer" to OOP. It 
seems to me like saying that "writeln" is more structured than "print"...

>   
>> I want to say just another thing. It seems that you are proposing
>> changes to gambas without having tried it enough.
>>     
>
> You are saying this without arguments.
>   
This is true. In fact, I wrote "it seems", I didn't wrote "you didn't 
tried ...". Sorry.

>   
>> beings. After some time, and two or three non-trivial applications
>> written in gambas, you will change your mind - you will begin to
>> appreciate it more than now. If not, you will then, and only then,
>> entitled to criticize. I am not saying that gambas is perfect: I feel
>> that you and me share many thoughts about programming, but I repeat:
>> give gambas some time.
>>     
>
> I am not criticizing Gambas. I am proposing an alternative syntax and
> seems that you can't understand that someone want to do that.
>   
Again, the common language we are using does not help us. There is 
difference between "enhancing" and "correcting". You intend to enhance 
gambas. But, when a thing is "enhanced", it is better than another thing 
that is not enhanced, and that other thing can be criticized about not 
being so complete like the enhanced one. Or, put in other words: every 
time I propose a change, I am criticizing (more or less mildly). The 
only things we can *not* criticize are those which are perfect - all the 
others are imperfect, and any proposed change to them is a criticism.

But anyway, don't take it bad. Call it "enhance" or "criticize", I think 
it's good for everybody. I find it a little boring a mailing list where 
the only arguments are "can't compile" and "found perhaps a bug"; 
besides those necessary things, welcome to new ideas and proposals - 
everyone in this list can take advantage.

I'd recommend anyone to use Intercal for their critical applications.

Regards,
Doriano