fbpx
Welcome, Guest
Username: Password: Remember me
  • Page:
  • 1

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

Implementing/"inheriting" C8 interface with default methods possible in xSharp? 2 weeks 4 days ago #13773

  mainhatten's Avatar Topic Author mainhatten Offline Posts: 108
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

Please Log in or Create an account to join the conversation.

Last edit: by mainhatten.

Implementing/"inheriting" C8 interface with default methods possible in xSharp? 2 weeks 4 days ago #13776

  robert's Avatar robert Offline Posts: 1542
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
XSharp Development Team
The Netherlands

Please Log in or Create an account to join the conversation.

Implementing/"inheriting" C8 interface with default methods possible in xSharp? 2 weeks 3 days ago #13784

  mainhatten's Avatar Topic Author mainhatten Offline Posts: 108
Hi Robert,

robert wrote: 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.
//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

Please Log in or Create an account to join the conversation.

Last edit: by mainhatten.

Implementing/"inheriting" C8 interface with default methods possible in xSharp? 2 weeks 3 days ago #13789

  robert's Avatar robert Offline Posts: 1542
Thomas,

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

Robert
XSharp Development Team
The Netherlands

Please Log in or Create an account to join the conversation.

Implementing/"inheriting" C8 interface with default methods possible in xSharp? 2 weeks 3 days ago #13794

  mainhatten's Avatar Topic Author mainhatten Offline Posts: 108
Hi Robert,

robert wrote: 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

Please Log in or Create an account to join the conversation.

Last edit: by mainhatten.

Implementing/"inheriting" C8 interface with default methods possible in xSharp? 2 weeks 2 days ago #13803

  Terry's Avatar Terry Offline Posts: 167
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

Please Log in or Create an account to join the conversation.

Implementing/"inheriting" C8 interface with default methods possible in xSharp? 2 weeks 2 days ago #13807

  mainhatten's Avatar Topic Author mainhatten Offline Posts: 108
Hi Terry,

Terry wrote: 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
www.xsharp.info/forum/public-examples/12...ms-and-net-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

Please Log in or Create an account to join the conversation.

Implementing/"inheriting" C8 interface with default methods possible in xSharp? 2 weeks 2 days ago #13813

  Terry's Avatar Terry Offline Posts: 167
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

Please Log in or Create an account to join the conversation.

Implementing/"inheriting" C8 interface with default methods possible in xSharp? 2 weeks 2 days ago #13818

  mainhatten's Avatar Topic Author mainhatten Offline Posts: 108
Hi Terry,

Terry wrote: 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

Please Log in or Create an account to join the conversation.

Implementing/"inheriting" C8 interface with default methods possible in xSharp? 2 weeks 2 days ago #13822

  wriedmann's Avatar wriedmann Away Posts: 2206
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
Wolfgang Riedmann
Meran, South Tyrol, Italy

www.riedmann.it - docs.xsharp.it

Please Log in or Create an account to join the conversation.

Implementing/"inheriting" C8 interface with default methods possible in xSharp? 2 weeks 1 day ago #13823

  Terry's Avatar Terry Offline Posts: 167
Hi Thomas
Thank you for your detailed reply.

Yes – it reflects the dilemma faced by us all, and is of course written from your perspective as a developer.

My comment was based upon what I would guess to be the perspective of the development team. It is just that - a guess - I have no direct involvement with them.

It has been obvious to me for some time that as things seemed to be evolving at ever increasing rate, some way of perceiving application operation was needed. Even if justification of such understanding required a bit of mental gymnastics, final perception should be easy.
My recent chit-chat post entitled “Jack and the Beanstalk” outlined my thinking on this.

Firstly I’d like to endorse the comments made by Wolfgang.

Secondly, your earlier comments re the road map: the road map was drawn up some time ago and based on rather broad statements made by MS at that time. My interpretation of them would have been the same as yours.

Thirdly being based on C#, X# will be able to follow a “route to the future” for business applications.
This third statement is, of course purely subjective, so I must do my best to justify it.
Our coding constructs, particularly in the business arena, tend to be 2 dimensional. It requires manual fiddle-faddle to cope with anything requiring 3-D thought. (perhaps in WPF).
Progress to Net Core via C#8 brings in the missing 3rd Dimension. A bit of cross-thinking leads me to view this as a completion of the typing set: e.g. none/usual, strict, and now duck as per Python. X# could follow at sensible pace.
If we all agree on a simple way of visualising 3-D operation (see J&B ) then suitable software tooling could be developed making things easier for all.
I hope these “thought snippets” make some sense.

Terry

Please Log in or Create an account to join the conversation.

Implementing/"inheriting" C8 interface with default methods possible in xSharp? 1 week 6 days ago #13834

  mainhatten's Avatar Topic Author mainhatten Offline Posts: 108
Hi Wolfgang

wriedmann wrote: 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:

Me ogling C# should not be interpreted as me disliking X#, but stems from 2 (rather large) influences:
I am currently not fit in the mixture of C# and VO/Vulcan allowed by the X# compiler and I have to fine tune general knowledge on programmin with DotNet specifics - MS docs, Stackoverflow, GeeksForGeeks often. There I find examples in C# and wonder if/how to move to X#. IlSpy installed and running should eliminate 70%, but I still have to verify if certain features are in Framework 4.6. Also multiple inheritance is not as bad as Java proponents always told until default methods surfaced. It is a good tool if you don't overdo it, using a more Mixin style, so that lures me to C#8 at the moment.
Second is: market for X# probably is even more limited than vfp. I have programmed in Fortran, various Pascal and ModulaII dialects, C, Fox2, Vfp, Java, Python and Javascript: after a few days basic constructs are no problem again - but I have to check how big the target market is. Own projects done typically either as learning expirience in new environment or do it in any interpreter for dev speed.

  • a language that is really easy to read
  • Second that totally - at first was sceptic on ":" as member divider, but I am sold when comparing "runtime usable code" vs "vfp compatible code". I might even take up -> alias again, so Dot signifies packages/modules.

  • a small development team that answers fast and reacts on development requests
  • No complaints here as well

  • a preprocessor that permits to save a lot of writing
  • Definately more than nice to have the option - although I try to keep it for last level, as to use it early lures you on slippery path. But I never tried to implement close dialects - that problem more suited to preprocessor than my usual stuff.

  • the use of some XBase language constructs like arrays
  • You probably read Roberts misgivings on vfp array implementation ;-)
    As I can remember fudging arrays in dbMan by appending numbers to variable names, even murky first implementations were welcome, but in vfp the better intermediate storage either is the cursor or a scattered object. Certainly nice to have more options again - esp if they are markedly faster than local storage, which vfp arrays are sometimes, but not always. .

  • a inbuilt powerful runtime compiler
  • Something used often in vfp as well - not tested the scope of possbilities in X# yet. In vfp we also have macro compilation, Execscript or can compile dynamic parts, for instance built from memo fields. Definately the easy way to build your own dynamic rule engine...

  • libraries to access legacy DBF data
  • My main target - not as remote data storage (SMB pitfalls make that to dangerous), but as client side cache, SQL stage table intermediate step, lookup storage and more. For purely local usage dbf is not legacy to me - I just argue strongly to not use it via remote or server side from client process directly. Also IMO an option dismissed to early as protocol - XML grew warts as well.

    From architecture subsets of normalized relational tables are much better than program first developed object trees, where impedance creeps in from both sides. Model the tables until they fit and leave out ORM or similar stuff trying to "correct" persisted data structures. No change of modeled persistance between front and database is my target - select only needed parts but define structures in persistance well enough to work with it as VM cache - if program stays more KISS, all the better.

    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.

    Similar to my idea of usage - I miss the immediate response of vfp interpreter when developing, esp. if target is nothing more than a chain of SQL datapruning steps. Probably for such tasks feeding special SQL via text files into ADO.Net might get some of the dev speed back, will see.
    As compiling takes more time IAC, get the most out of it for program quality by ditching USUAL vars, parameters and return values from code and staying with Core, RDD and strict typed functions. Best if dbf can accomodate all data types directly, which ADS seems to do best at the moment, so that would be first enhancement to dbf to ask for. So for vfp compatibility, I'll add some more overwrite methods with correct method signature.
    But supreme for me was having the code as open source - not again depending on a black box (although at the moment I understand only small part of X# internal machinery...) After Lianja switched course to implement "cursors" only as JS cursors with added methods for ARM and web, I was unable to do anything and left - here I can at least bang my head against already existing code if I am the only one interested in specific enhancement ;-)

    regards
    thomas

    Please Log in or Create an account to join the conversation.

    Last edit: by mainhatten.

    Implementing/"inheriting" C8 interface with default methods possible in xSharp? 1 week 5 days ago #13843

      mainhatten's Avatar Topic Author mainhatten Offline Posts: 108
    Hi Terry,
    quote="Terry" post=13823]Firstly I’d like to endorse the comments made by Wolfgang.[/quote]
    I'll answer here only few points, as I wrote a lot on Wolgangs comments.

    My comment was based upon what I would guess to be the perspective of the development team. It is just that - a guess - I have no direct involvement with them.

    My point is that I am afraid the things luring VO/Vulcan devs here might not be that tempting to remaining (perhaps should say persevering) vfp devs. Despite the syntax similarities there marked differences in creating applications. Only a few vfp devs writing here, I'd hoped more would chime in.

    It has been obvious to me for some time that as things seemed to be evolving at ever increasing rate, some way of perceiving application operation was needed. Even if justification of such understanding required a bit of mental gymnastics, final perception should be easy.
    My recent chit-chat post entitled “Jack and the Beanstalk” outlined my thinking on this.
    Secondly, your earlier comments re the road map: the road map was drawn up some time ago and based on rather broad statements made by MS at that time. My interpretation of them would have been the same as yours.
    Thirdly being based on C#, X# will be able to follow a “route to the future” for business applications.
    This third statement is, of course purely subjective, so I must do my best to justify it.
    Our coding constructs, particularly in the business arena, tend to be 2 dimensional. It requires manual fiddle-faddle to cope with anything requiring 3-D thought. (perhaps in WPF).
    Progress to Net Core via C#8 brings in the missing 3rd Dimension. A bit of cross-thinking leads me to view this as a completion of the typing set: e.g. none/usual, strict, and now duck as per Python. X# could follow at sensible pace.
    If we all agree on a simple way of visualising 3-D operation (see J&B ) then suitable software tooling could be developed making things easier for all.
    I hope these “thought snippets” make some sense.

    On the topic of GUI, if given task and funds to start from zero, I'd probably aim for something close to Cell.Js or Jasonette from Ethan Glichtenstein - interesting read if you don't mind reading up on concepts which failed to get enough public traction...
    Adding Python and duck typing again - current resolve is to get a firm standing in Dotnet-strict typing again, then perhaps look gain at USUALs, static type called dynamic or adding an interpreter again, which might be Python or C# based. Waaaay in the future.

    regards
    thomas

    Please Log in or Create an account to join the conversation.

    Implementing/"inheriting" C8 interface with default methods possible in xSharp? 1 week 5 days ago #13845

      Terry's Avatar Terry Offline Posts: 167
    Hi Thomas

    I look at things slightly differently. There may be a different way in to dot Net which suits Vfp programmers.

    Having said that, I would encourage those programmers to look at XSharp as a staging post to the future. Which, as I see it, will be .Net based.

    It has a competent and enthuistic development team, and user community with broad rnge of backgrounds willing to help (as quiclky as possible) with any transitioning problems.

    The exact path along which future development trends will take us is difficult to predict. One thing I am certain of is that no object has more that 3-Dimensions to address and MS driven (.Net) technologies cover all aspects. All derivative languages of CSharp can potentially follow at their own pace.

    I know nothing about Vfp, but FWIW if you think Cell.js is a better route I'd suggest looking to see if there are any initiatives tackling the problem of using it's scripting libraries on the CLR platform. (eg as per IronPython).

    Things will evolve - both software tooling and programming techniques. Just how remains to be seen.

    Terry

    Please Log in or Create an account to join the conversation.

    • Page:
    • 1