std library hooks

[Artur Skawina]

On 04/16/12 07:17, Nick Sabalausky wrote:
> "Walter Bright" <newshound2 at digitalmars.com> wrote in message 
> news:jmflrl$5ub$1 at digitalmars.com...
>> On 4/15/2012 4:19 PM, Manu wrote:
>>> On 16 April 2012 02:09, Walter Bright <newshound2 at digitalmars.com
>>> <mailto:newshound2 at digitalmars.com>> wrote:
>>>
>>>     On 4/15/2012 3:04 AM, Manu wrote:
>>>
>>>         Wow. This all sounds... really unpredictable.
>>>
>>>
>>>     It isn't. People are way overthinking this.
>>>
>>>
>>> Maybe, but I still think that anyone who doesn't have the equivalent of a 
>>> Ph.D
>>> in compiler authoring probably won't understand this, and will become 
>>> frustrated
>>> when things don't work as expected.
>>
>> Please, please stop thinking this is Ph.D complicated. It is not. Linkers 
>> are old old OLD technology going back to the 50's. They haven't improved 
>> much since then. They are ridiculously simple (compared with the 
>> complexity of modern languages) and simple-minded tools.
>>
>>> A nice API to register hooks just seems so much simpler, and more 
>>> conventional.
>>> Most libraries I've worked with have such an API, I think it'd be pretty
>>> intuitive to many users to follow the same pattern in druntime too.
>>
>> Hooks add bloat and complexity to the library, and I don't see how they 
>> are any easier to use than simply providing your own explicit function 
>> with the same name that automatically overrides one in the library by the 
>> mere fact that it exists.
>>
> 
> It would be easy *IF* it worked that way. But it clearly *doesn't*. There's 
> a whole host of caveats that all stem from the specifics of the underlying 
> algorithm used by whatever particular linker you happen to be using.
> 
> "Here, I'll provide my own X."
> 
> Multiply defined symbol X.
> 
> "WTF? Walter said it should work!"
> 
> [Posts on the NG and waits for help]
> 
> "So 'Multiply defined symbol X' REALLY means 'If you provide X you also need 
> to provide Y and Z'?"
> 
> Yup.
> 
> "WTF! Ok fine, here's Y and Z..."
> 
> [Works fine. Few weeks later, you make an unrelated change in some other 
> section of code]
> 
> Multiply defined symbols X, Y and Z.
> 
> "God damnnit."
> 
> [Waste time hunting down the issue]
> 
> "Jesus, so that unreleated change added a call to phobos's 'foo', which in 
> turn calls druntime symbol W, which wasn't previously used by my app, but it 
> is now, and it's not provided by my X Y and Z stuff when all I wanted to do 
> was just replace X, so now I had to figure out that this totally nonlocal 
> change means I *also* have to provide a Q now, oh and nothing ever told me 
> so because apperently this is so super-simple that none of it needs to be 
> documented. So fine then, linker, here's your damn Q..."
> 
> [Works again until druntime/phobos is updated]
> 
> Multiply defined symbols Q, X, Y and Z.
> 
> "Fuck, what now? I didn't even change *one line* in my app!"
> 
> [Waste more time...Loose more hair...Enlarge the head-shaped dent in the 
> wall...]
> 
> "So...druntime changed: that particular object in druntime now *also* has a 
> new symbol F which some *other* function in druntime or phobos has been 
> changed to now use. Gah...fine, take the damn F..."
> 
> [Some poor sap tries to use a different linker and the whole damn thing 
> blows up]
> 
> "FFFUUUUUUUUUUUUUU!!!!!!" (Insert accompanying meme picture here)
> 
> You *seriously* expect to convince people that qualifies as "ridiculously 
> simple"? C includes make more sense than that. The linker implementation 
> might be simple, but the implications sure as hell aren't.

You do realize this is exactly how it is supposed to work? You *want* the
build to fail if the implementation you were overriding parts of has changed.
Then you can evaluate the situation and adjust your code if necessary.
Having the build silently succeed, resulting in a random mix of "new" code and
overridden "old" code is not a good idea - the reason the symbols were placed
in the same section/object/unit is likely because they are *not* independent.

As long as you have a) a defined interface, and b) properly built library,
then there is no problem. The former lets you completely override all of the
API and the latter means that unrelated symbols don't cause trouble. Hence
fixing bugs in (a) and (b) is better than trying to invent another symbol
hijacking scheme. 

Right now this also is not a problem in practice cause the libs are not stable,
and the stock druntime and phobos are not likely to be used for anything other
than toy examples and trivial programs. Something else to consider is that if
you provide hooks people will use them, work around library limitations and
bugs, but will then have less incentive to submit the fixes upstream. 

artur