In T7675#139861, @tasn wrote:

It's not just that, you also need to make sure that static is only allowed on classes and not interfaces, and you can only implement where it was defined, not elsewhere.

Thanks @q66, fixed in rEFL8a8a833837f7217aea0a33f4f7afbb6edfb103c4

That's one of the suggestions I made above. I'm fine with that too, though that's a different discussion.

Hm? why not just rename current @class to @static (which is easy and quick) and then only re-add @class later if it ends up being needed?

It's adding back @class and then adding @static that is just like what @class is now. OK, thanks for the feedback!

If it's just renaming to @static, then that's fine and easy

Gotcha, good to know. Then @static is maybe the best option for T8118. @q66, anything to contribute regarding the syntax suggestions?

In T7675#139845, @tasn wrote:

Would it be a reasonable compromise to borrow the @static modifier from Python and use it alongside @class?

@static sounds like a good solution for T8118, but what's the advantage over just "floating"? Compatibility with languages that don't allow floating functions? How does C# handle "floating" structs btw? Do they have to be in a class too or is it OK to have them floating?

Do you mean the Text_Factory classes? I'm wondering what would be the case for them to have actual @class dynamicity.

In T7675#139819, @tasn wrote:

@lauromoura: I think I already addressed your comment too in my reply to @felipealmeida , please let me know if that's not the case.

@lauromoura: I think I already addressed your comment too in my reply to @felipealmeida , please let me know if that's not the case.

I'll let other people chime in. If nobody else opposes, then IMO you can go ahead and reinclude it. If that happens, then we need a solution for T8118 first, IMO.

By size I mean typing more. I'm not against it per se, but for static use it doesn't look like a good tradeoff to me. This is going to uglify bindings and I don't really see much of a difference in change the name of the method or pass a different type. It actually creates one more point for error, where people can pass wrong classes, they can't when the class is embed in the function name.

In T7675#139808, @felipealmeida wrote:

Do we have a use-case where we get the class type dynamically? If we use it statically, this is just syntax-sugar. And not even very sweet since it makes the code bigger.

By size I mean typing more. I'm not against it per se, but for static use it doesn't look like a good tradeoff to me. This is going to uglify bindings and I don't really see much of a difference in change the name of the method or pass a different type. It actually creates one more point for error, where people can pass wrong classes, they can't when the class is embed in the function name.

Do we have a use case? Features are nice, but I think they must be justifiable.

About factories: what is the difference between:

Do we have a use case? Features are nice, but I think they must be justifiable.

The problem is with singletons/factories + inheritance, as implied from the context of this discussion.

Factories and singletons are still implemented on various places, and just work normally as in other languages.

Marcel, I keep in repeating myself. I already addressed what you just wrote numerous times like at the last paragraph of: https://phab.enlightenment.org/T7675#139789
Even with non-class functions, C functions can't access overridden functions in C# (or if they can there, not in all bindings), and if there's a way to make it work, then there will also be a way to make it work with overrides not just overwrites.

The differences do matter quite a lot, if we build up an API in .eo files that relies on this feature (for example, overwrite a API on the class, which is then called from inside efl) then this is not available in C# as this is 1. Not known to C# people 2. Not possible while calling it a class function. ( You can replace C# with any languages I gave you above)

Yeah, I understand that new means override (now that we have discussed it further), but as I said, in my last comment and previous ones, it doesn't matter, because this logic is handled by C anyway. The same scenario you just described would break even with non-class functions because the C code will not call your C# code. So I don't see why the obsession with this specific case of class functions when the same functionality is overall broken.

I think you did not understand what the *new* function in C# is doing for static functions. If you use it, it tells you that function, where you declared it is shadowing the definition that is lower in the inheritance structure. Means that by anonymous calling from inside the class, everything inheriting from this class will call the new function. Function calls inside classes we have inherited, are still going to the original definition, not impacted by the *new* API. Which is the behaviour we have right now

Thanks for adding the clarifications, though this is something I already addressed at the bottom of: https://phab.enlightenment.org/T7675#139789

@tasn I am talking about the plain difference between what is called a class function in C# and what we before called class function in eo (before my patch).

@tasn is right - from the point of view of a user - it's the same. even if c# and java couldn't do it then its a "c only feature" - they can CONSUME it and make use of it from what efl does in C.

And also you haven't addressed the other point, which is even if you were right about this point, these shouldn't live in the class but rather in a related namespace.

Read what I said at the bottom of the last post. It doesn't matter because everything is done in C anyway. You don't get the behaviour you're describing in normal non-class functions either. It always behaves like overloading because it calls C directly under the hood, doesn't actually use the language's object system.

This is overloading not overwriting, you wasted your own time. Please lookup how do do overwrites in c#

Actually, now I'm really pissed off you are wasting my times and spreading false information, here's a fucking C# example:

using System;
					
public class Program
{
	public class A {
		public static void foo() {
			Console.WriteLine("A");
		}
	}
	
	public class B : A {
		public new static void foo() {
			Console.WriteLine("B");
		}
	}

Stop trying to twist my words and start reading them. I never fucking said ask Tom for changes in eo. I said, when you fundamentally change existing code, ask the people who wrote it why it was the way it was. Not just me, not just Eo. I talked to raster a lot when I redid the text system way back when, I talked to everyone a lot when I did the object system, I talked to cedric when I touched the relevant edje parts. It's just common sense to ask people who actually know the code why things that you find weird are done the way they were. I don't understand why you keep on trying to ridicule this statement. It's obvious and should be the basis to everything you do.

Let's stick to the technical, the rest will end up in another rant and more weird arguements that lead to the conclusion that I need to ask you. Note is taken "ask Tom for changes in eo"

I didn't say you have social problems, I was complaining exactly like the above. I said the big issue with this change is the broken process (which is a social aspect, not technical) that lead to you changing a massive piece of code without asking *anyone* that's been involved in it's creation and design when I'm on IRC, mail and read the ML. The only one of the "reviewers" that actually maybe was involved is q66, but he said he wasn't asked to review any proposals (as evident by this ticket and lack of participation) but rather to review the code. It's not about me, I just don't understand why you'd make such a big change without first gathering information.

Okay, after i have received another rant via PM, with the conclusion that i have a social problem:

1. No OOP framework does support that. Not a single one, all you can do is basically overloading but newer overwriting, which leaves you with static dispatching instead of dynamic dispatching. Coming from a math background, class functions in a argebraic sense are also static dispatched, and the same, per group / class. (https://en.wikipedia.org/wiki/Class_function_(algebra))
2. Whatever you have want yo model with a overwritable class function, you still can do it. Just have a property that returns an object that implements the API. Higher hirachies can pass there theire own object, with theire own implementations. (Whatever was possible still is possible)

@cedric