Implementing/"inheriting" C8 interface with default methods possible in xSharp?

[mainhatten]

Hi,
separating interface and implementaion into different assemblies is supported in Dotnet. As all compiles down to IL and can be ported to other language, cross language (defining an interface in C#, implementing in xSharp) should be possible as well.

As C#8 supports a few goodies which xSharp as compiler does not support at the moment (plans for enhanced C#8 support seen in roadmap), I wonder if current xSharp-compiler can handle xSharp classes implementing pre-compiled C#8 interfaces from other assembly with already coded/compiled default methods - which should be already in the IL - without the need/rule to overwrite all interface methods and instead reusing the C#8-coded and compiled default methods ?

If it is possible, ILSpy might make the additional effort small enough to try out a few (perhaps hare-brained) ideas and at least get a better grip on things doable in IL. If this is currently impossible (as compiler perhaps needs to be enhanced for "consumption" of interfaces with already coded default methods), please stop me from repeatedly running head-first into currently unbreakable walls.
"
tia
thomas

[robert]

Thomas,

Adding default methods to interfaces is NOT possible at this moment in X#.
We have talked about it and it is on our to list, just like some other things from the latest C# compilers, such as local functions, USING VAR declarations, IN parameters (ref readonly parameters), enhanced nullable support, wait foreach, exception filters, collection initializers, indices and ranges etc.

We plan to add many of these things to the compiler in the cause of this year. But at the same time we have to make sure that we can compile all FoxPro code, and that is a bit more challenging I must admit.

Robert

[mainhatten]

Hi Robert,

Adding default methods to interfaces is NOT possible at this moment in X#.
We have talked about it and it is on our to list, just like some other things from the latest C# compilers, such as local functions, USING VAR declarations, IN parameters (ref readonly parameters), enhanced nullable support, wait foreach, exception filters, collection initializers, indices and ranges etc.

We plan to add many of these things to the compiler in the cause of this year. But at the same time we have to make sure that we can compile all FoxPro code, and that is a bit more challenging I must admit.

Too bad - I had hoped to show some working code instead of trying to describe my ideas/wishes in English...
Where am I coming from ?
I think the GUI classes for vfp should NOT follow the the example of the VO GUI classes implemented in class hierarchies, but should be implemented in several interfaces as default methods and access/assign methods.

Code: Select all

//pseudo code
Define Interface IPosition
   Get/Set Left
   Get/Set Top
   Get/Set Height
   Get/Set Width

Define Interface IColor
   Get/Set ForeColor
   Get/Set BackColor
   Get/Set DisabledForeColor
   Get/Set DisabledBackColor

Define Interface IFontStuff
   Get/Set FontName
   Get/Set FontSize
   Get/Set FontBold
   Get/Set FontItalic
   Get/Set FontUnderline
   Get/Set FontStrikeThru
   Get/Set FontOutline
   Get/Set FontShadow
   Get/Set FontCondensed
   Get/Set FontExtent

define Interface ILisa
    method Load
    method Init
    method Show
    method Activate

Define Interface IWithControl
   get/set enabled
   method When()
   method GotFocus()
   method valid()
   method LostFocus()
   method interactiveChange()
   method ProgrammaticChange()

define interface IActionEvent
   method Click()
   method RightClick()
   Method Esc_Cancel()
   method Enter_Default()

define interface IValue
    get/set value_or_text

define interface IShowInfo
    get/set Caption
    get/set TooltTipText

Which either gets slapped in the right combination onto the corresponding control for each vfp baseclass of [WinForm,WPF, Mono,Android] or as a vfp class which has a corresponding.oGuiControl of those GUI families, which is subsequently shown and manipulated.

I personally think long range future lies with the XAML based branch of WPF, Mono, UWA/UWP or Razor/Blazor even if WinForm has made a huge comeback. If the xSharp "default" port for a vfp app with GUI is implemented on the WinForm.branch because that is known much better from expirience implementing VO-GUI, great, as "shipping early" is a feature as well - but do it in a way showing the way to port in parts without total rewrite to Mono/MonoDroid/WPF/Blazor.

Few of the interfaces will need no change (IPosition) a few others mostly a typical MS property rename to get operational (vfp "enabled", WinForms "Enabled", WPF "IsEnabled"), some a more extensive rewrite. The fox GUI interface was created for different OS (DOS, Xenix, Windows), vfp was at start still (Windows,Mac). It offers only tiny part of the options of WPF, but can serve as a common denominator for different GUI sets, making "small subset" a benefit, not a detriment.

Yes, I realize that just manipulating WPF properties is miles away from the prefered state managment of IPropertyNotified, but I left that out on purpose to concentrate on interfaces with default methods (and I already typed too much prose).

comments?
thomas

[robert]

Thomas,

All that you describe can be done with classes and interfaces without default method support.

Robert

[mainhatten]

Hi Robert,

All that you describe can be done with classes and interfaces without default method support.

True. But my first programming mantra is to keep code DRY. There are ways to minimize repeating same or similar code implementing same interface on multiple classes, but they tend to either lengthen the inheritance chain, stuffing things into classes not needed in the particular branch and brittling the code, or adding further objects, each for specific subtask(s). Using extension methods is also an option to avoid repeating code - the argument or code smell of coding just function libs with object usage IMO is stronger on extension methods.

I view augmentation via interfaces sporting default methods as superior to the previous approaches (at least from code brevity/quality, have not considered possible runtime penalties) and will not argue for a pattern I believe to be marred if I think better way is just around the corner.

my 0.02€
thomas

[Terry]

Hi Thomas

Yes - if I understand you correctly all you suggest is desirable.

But as far as I know these things are not supported in the .Net Framework. Probably can't be because they require changes to the platform.

They are therefore only available to a target framework of .Net Core 3.0 running C#8.

Very much for the future, but no reason for them not to be borne in mind.

Terry

[mainhatten]

Hi Terry,

Yes - if I understand you correctly all you suggest is desirable.
But as far as I know these things are not supported in the .Net Framework. Probably can't be because they require changes to the platform. They are therefore only available to a target framework of .Net Core 3.0 running C#8.

You are totally correct and thx for pointing out that I had left a bit of my base assumptions unmentioned.
xSharp projects currently compile against .Net Framework 4.6

Very much for the future, but no reason for them not to be borne in mind.

Maybe I misunderstood/overinterpreted, but from Thread Video: X# Winforms and .Net Core
https://www.xsharp.eu/forum/public-exam ... -core#9049
I had reasoned that not going to Dotnet Core at the moment was due to VS integration, the code of all xSharp.Core would compile..
I had also equated that with "new stuff" including RDD and so on, but not running against VO dlls, dunno if that was a mistake or relevant.

As Vfp should not require any VO-licensed stuff (which I don't have...) why not jump now to Core, as Framework will stay at 4.8 forever ? One of the aims of switching to xSharp is not being left while train moves on, with me hoping to target Xamarin/Android, as Win desktop platform is supported well enough on any VM having 32-bit-support and even web backends can be done via FoxInCloud - at reasonable cost for existing solutions, only depending on Windows server and excluding Linux web backends.

MS analyzer tool found 1 missing .H file for Core project, although I am not certain if fixing that might show new errors...

So I would prefer Sharp/vfp to switch over to DotNet Core and use the new (at least released and already patched in late 2019) capabilities before implementing vfp GUI parts in a way determined by current dependencies, as "other GUI" aka Xamarin, MonoDroid, Blazor are the things I want to target. Even Raspberry Pi might become interesting, as PiHole tempts me to get one - currently have PiHole running in a VM.

thx for the interest and taking the time to point me to my leaving out part of own thought process in description.

regards
thomas

[Terry]

Hi Thomas

I agree with all you've said.

BUT I think you are arguing from a purely technical perspective.

All you've suggested may appear straight forward, it's good advice but I'll guarantee it won't be so easy in practice; implementation will take time and human resources.

The development team must take into account the need to generate revenue. Failure to address customers current requirements would compromise that.

Terry

[mainhatten]

Hi Terry,

I agree with all you've said.
BUT I think you are arguing from a purely technical perspective.
All you've suggested may appear straight forward, it's good advice but I'll guarantee it won't be so easy in practice; implementation will take time and human resources.
The development team must take into account the need to generate revenue. Failure to address customers current requirements would compromise that.

Ok, I'll try to rephrase my argument from the economic side of/for xSharp developers. As far as I have grokked history of xSharp is tied to VO and Vulcan users which received no or unsatisfying bugfixes and were given no perspective. Seems to be also worry that in the future some previously used runtime would cease to work - unclear if this is connected to previous runtime being 32-bit (wich might be dropped when 128bit OS with 64 subsystem arrives) or other reasons. Developers were already working on previous runtime and used smart in-between-step of using VO dlls. Customers the group already using VO and closer cousins than vfp. Makes total sense if your company is built on software grown over many years. VO compstibility extremely high as those already bought dlls were reused.

Vfp in its heyday probably had larger # of devs and apps, but many moved themselves and their apps since 2007. Most very large apps are already ported. Those that did not move have stable systems, where faster CPU and SSD fixed problems of growing data sizes. They can build web apps if needed, with moderate server running the form and AJAX-updating client side HTML. Communicating with current "evolved" services PITA, but you can COM into Java, Dotnet or host Dotnet runtime if you wish to avoid low level picking apart ever-more automated XML and similar stuff. Not pretty, but doable. Backend via C/S already the stength of vfp, if backend uses SQL.

What does xSharp offer those remainers ? Another desktop with better Winform/GUI integration. Certainly, but those needeing eye candy already bought activX or Dotnet controls and integrated them.

Web: already doable or done, via FoxIncloud or COM called by server, either via West-Wind or AS#p.Net. No pressing problem - FoxInCloud can port even to mobile with a GUI-refit (not total rewrite), but is server based like old ASP or Java Vaadin solutions - no way to run offline. Possible to run on Linux if one is not afraid of MS litigation, but not really needed as Win is standard desktop OS for most users.

As I am a hired gun programmer, not tending own solution - when could I honestly say the effort of porting to xSharp is worth it if one of my previous customers asks me about it? And there will be some effort,

I stayed in vfp for several reasons: long term contract consolidating/datamining big iron data, a few data upsizes to various backends,sometimes asking for ingenious ways to keep most of existing code while rearchitechting to eliminate most perceived warts - and the personal preference for vfp cursors as cached/mirrored remote used data in MVVM pattern without ORM twistings, which I think already sport most of the benefits Flux (re-)introduced to web programming: Single Source of Truth, redundance-free normalized data store and has benefit of SQL over it and backend. Have done other languages when starting years ago and did a few more last decade...

This pattern I like - found in cursoradapter, conflict managment and buffering I believe will benefit current users VO, as I think backend handling of vfp is superior, but those who already are customers could do half of that out of the box via ADO.Net if they really want to and redesign their apps a bit.

Only thing really missing for vfpers is ARM/mobile app to install, PWA-web client able to work offline (doable via WASM later) and IoT starting from Raspberry down. If customer needs that or future new stuff - he needs DotNet with xSharp, but more current versions like Core 3 upward. For most others, maintaining current vfp is good enough. With less fear of "stick of failing runtime", you need high compatibility AND carrot of more than WinForms. So designing GUI for other options right from the start IMO is biz sense and avoids double effort. Similar to putting correct wheels on your car depending on destination, for ex. before driving into ski area in winter, tooling up to Core might be beneficial

Adding vfp highlights/"can't do without its" first would be adding to "worth" of xSharp to build solutions (and is aligned with my personal bias, so weigh with care) as it might add options for VO to upsize to C/S with another/better pattern, so biz benefit even if few vfp'ers jump aboard.

I hope to sneak my favorite state managment into code perhaps done in C# or do ports where it makes sense and.I am sorry that so few vfp coders are interested/helping currently, but xSharp is far from usable to replace vfp apps in current state for those up to their ears in maintainance. Just having xSharp as another option is not enough to get them into FOX, they need new biz benefit.

I personally want to have an alternative middle layer if asked to do Dotnet (and be up-to-date there again), perhaps (help) redesign vfp apps to mobile and better web, but uncertain if I can really use it in the future, so I am only helping a bit and learning - with resolve to get into FOX for a few years via percentage from gigs if they materialze, otherwise it is just a mixture of hobby, mental gymnastics coupled with learning and (perhaps) pipe dream

still mostly tech based, but biz motives intertwined

my 0.02€
thomas

[wriedmann]

Hi Thomas,
even if I come from Clipper/VO through Vulcan.NET to X#: X# has its benefits for business applications offering things that C# or other languages don't have:

• a language that is really easy to read
• a small development team that answers fast and reacts on development requests
• a preprocessor that permits to save a lot of writing
• the use of some XBase language constructs like arrays
• a inbuilt powerful runtime compiler
• libraries to access legacy DBF data

These are the things that are coming to my mind immediatly - and therefore I'm using X# in many applications in the Core dialect - without using the X# runtime.
Wolfgang