On Fri, 27 Feb 2009, Kleyber Derick wrote: Hi,
> Well, I have some FWH classes which I have changed in order to work in > all my apps. So when a new FWH release is come, I don`t have to change > the original class and neither to put the new prg with the changed class > in my app, I just use OVERRIDE or EXTEND CLASS in my own prg and all is > solved. OVERRIDE / EXTEND CLASS does not have to work in all cases. In some situations such functionality nay even break class definitions and cause unpredictable behavior, f.e. it does not change any classes which already inherited from modified class so accessing instance variables may use wrong indexes and operate on instance area which belong to other ancestors. Such things can happen in both compilers: Harbour and xHarbour. > Anyway, Teo has showed me a way to change it to a function in Harbour, > I will test it and give you a feedback. If you have another suggestion, > will be welcome too. I do not like that people use it because we cannot support functionality which is broken by definition though I understand that locally it may be usable in some situations. I do not want to add it to core code as documented feature because I cannot promise it will work in the same way in the future when we extend/modify our class code. Keeping it alive may be serious problem in farther developing. But in contrib/xhb directory we have xHarbour compatibility library and header (.ch) files which emulate some of xHarbour features we do not want to add to core code for different reasons. Some of them also use unsupported and undocumented functionality so I think that if I add yet another header file xhbcls.ch with PP commands for above nothing worse will happen. I'll commit it ASAP but please remember that it's undocumented and unsupported by us functionality. best regards, Przemek _______________________________________________ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
