Then they just need run 'svn ann' or equivalent for whatever RCS they  
are using to clearly see which user created the the problem.

If employees constantly cause problems by doing this then tell them  
to stop it. If they won't then they're bad employees.

I don't think we should cripple a language because a couple of  
companies may have shoddy management and bad communication.

The reason I'm strongly against this is that publicly available  
libraries will may end up freezing their classes "to keep everything  
standardized" which would cause us headaches, and in particular me  
since I'd end up writing the circumvention mechanism.

A proper revision control system yields a grand paper trail. Leave  
tracking of revisions and who-wrote-what to the proper service, the RCS.

None the less, it was enlightening to learn some people thought this.

On 11 May 2006, at 22:03, John Gabriele wrote:

> On 5/11/06, rob <rob / motionpath.com> wrote:
>> Re-opening classes is one of the things that makes ruby great. [snip]
>>
>> Why so precious? If you don't want people to modify your code say so.
>> If they go ahead and it blows up it's their fault.
>
> Not to take any sides, but I think I've heard the argument go: if
> you're working on a team on a large project, and all of a sudden
> "your" class breaks, management doesn't want to hear about someone
> else opening your class... they'll just see your name on the class
> causing the hold-up and then it *becomes* your problem.
>
> In the typical "enterprise scale" cubicle farm environment, team
> leaders are constantly looking to find someone to blame for the
> project being behind. B&D languages like Java lend themselves to rigid
> compartmentalization that yields paper trails.
>
> It's interesting to think about the dynamic there -- between the
> language and the cube farm.
>