Log of the #nice channel on irc.freenode.net

Using timezone: Central European Time
* arjanb leaves08:06
* bonniot joins09:43
* bonniot leaves11:11
* arjanb joins15:43
* bonniot joins16:22
<arjanb>hi16:23
<DRMacIver>Hi16:25
<bonniot>hey16:29
<arjanb>to answer the question of yesterday, no it doesn't help with operators because it uses a similiar model as javacc16:32
<bonniot>ok16:33
<arjanb>so switching isn't worth the effort on the short term16:34
<bonniot>yeah. although it would be interesting what other benefits antlr could bring. in speed or features16:36
<DRMacIver>Hm. 17:02
I just tried to use a Nice feature in Java and then felt sad inside when I realised I couldn't.
<bonniot>lol17:03
which one?
<DRMacIver>Nothing flashy. Just the default constructor.
So it's easy to write my own.
It's just a shame to have to. :)
<bonniot>exactly
<DRMacIver>Although of course the Nice default constructors conflict with our coding conventions. 17:04
I wonder how one would find a way around that.
<bonniot>yes, but coding conventions are made to get around java limitations17:05
what do you mean?
<DRMacIver>In our coding convention, member fields are named mProperty, while constructor and method arguments are named property.17:06
So the private field mFoo would have accessor getFoo, mutator setFoo and constructor argument foo.17:07
<bonniot>but if you could use nice, you could get rid of those conventions, no?
<DRMacIver>They don't really seem any less relevant in nice as compared to Java.17:08
<bonniot>they are, because the idea in nice is that you can start with a public field, and if you need an accessor or mutator method later, you can do that without changing client code17:09
same as being able to use the default constructor at first, and be able to override that later if needed
simple field, not necessarily public17:10
<DRMacIver>That suffers from a consistency problem.17:11
There are good arguments in favour of accessors.
<bonniot>like?
i mean in java i understand they are needed, but in nice?
<DRMacIver>The big one in practical terms being that the JavaBean specification requires it, so if you want to write components for Java projects in Nice you need to use them. :)
<bonniot>but the nice compiler generates get and set methods17:12
* DRMacIver blinks
It does? Since when?
<bonniot>so it matches the javabeans spec
* DRMacIver was not aware of that.
<bonniot>dunno, must be in the NEWS file
:-)
not so recent
<DRMacIver>Anyway, the reason for the convention is to help the scope of variables readily visible.17:15
I've no strong inclination towards it.
But it does have some readability advantages.
<bonniot>readily visible?17:16
<DRMacIver>When I'm referring to mFoo somewhere within a method I know it's a field rather than a local variable.
Or rather the person reading my code does. :)
* DRMacIver doesn't have any desire to defend the convention. I didn't come up with it, and I'm not especially attached to it. :)17:17
<bonniot>ok. although one could say a method where it's not clear what are the local variables is too long and should be refactored ;-)
<DRMacIver>Yes one could. :)17:18
'clear' and 'immediately' apparent are not the same thing though.17:20
err. and 'immediately apparent'
I think the idea is that there are features of the code which should stand out at a glance and this is one of them.17:21
<bonniot>ok, but if that's important then it should be the job of the editor to use different fonts or something. such convention just seems backwards to me
<DRMacIver>Yes, but arguments like this have been going on for years (cf. hungarian notation) and they're never won. :)17:22
<bonniot>to me a good variable name is much more important. whether it's a field or a local var is acutally often an implementation detail, and I would actually prefer not to know most of the time. and if it matters, yes, it should be easy to find out17:23
you mean ppl are still using hun notation? ;-)
<DRMacIver>Joel Spolski for a start. :)
By the way, I've noticed that Nice generated classes often cause jad (a java decompiler) to seg fault.17:25
Any idea why that might be?17:26
<bonniot>sure
lad is surely targeted at decompiling javac generated code
nicec generates code that it probably never tested on
jad bug in any case, provided the generated class is valid17:27
<DRMacIver>Fair enough.
You're using BCEL to generate the byte code, right?
<bonniot>nope
<DRMacIver>Oh. Hm. Wonder where I got that idea.
<bonniot>gnu.expr, which was written for a scheme->jbc compiler17:28
<DRMacIver>Ah
<bonniot>but not so cleanly separated as a library
problable bcel would be better
<DRMacIver>Ah. I see you are using BCEL somewhere in the compiler (in the class stripper apparently).17:29
That must have been what confused me.
s/compiler/project/
(It's part of tools.util)
<bonniot>hum, what is that class stripper?
ok, it's not a core tool for sure, not used by the compiler17:30
<DRMacIver>No idea. I'll take a look.17:31
Removes method code from class files apparently. Your javadoc comments aren't very informative. :)17:32
<bonniot>i think it was a one time tool to generate a stripped version of java.util with generic signatures
<DRMacIver>Ah, right.17:33
* bonniot leaves18:29

Generated by Sualtam