|
You're welcome. If you think it it helps you out, please give a like, thanks Kevin.
|
|
|
|
|
These changes make me wonder if using an abstract class doesn't already offer these facilities. Would you use them ? Don't these extensions contradict the "classic" model ? Your view ?Quote: 1. Default Implementations: As mentioned earlier, interfaces can now have default implementations of methods. This allows you to add new methods to your interfaces without breaking existing implementations.
2. Static and Instance Members: Interfaces can now contain static methods, instance methods, and operators.
3. Private and Protected Members: Interfaces can now contain private and protected members. This can be useful for providing helper methods used by the default implementations.
«The mind is not a vessel to be filled but a fire to be kindled» Plutarch
modified 6-Aug-23 10:09am.
|
|
|
|
|
These features may make sense because in a sense, they now support multiple inheritance in .NET.
If interfaces can have methods and instance members, and you can derive from multiple interfaces, then that would be a pretty close approximation of multiple inheritance.
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
Richard Andrew x64 wrote: a pretty close approximation of multiple inheritance. in a way abstract classes do not ?
«The mind is not a vessel to be filled but a fire to be kindled» Plutarch
|
|
|
|
|
There must be ways to use abstract classes that I never thought of.
I never saw it as a multiple-inheritance mechanism. But I am a simple-minded soul.
|
|
|
|
|
You can't multi-inherit abstract classes, but in all versions you can inherit from a base class and multiple Interfaces.
So adding default methods to Interfaces brings them a lot closer to a class and a fair impersonation of multiple class inheritance - remember that the only real difference between a "traditional" Interface and an abstract class is that the interface contains no code but enforces what you must implement, while the class provides methods and requires implementation.
It's useful, but ... just like var and dynamic it's wide open to abuse, and going to give problems when you inherit "lazy coder" apps.
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
Sounds like one is "attaching" new behaviour versus simply inheriting it, or promising it. Component-based architecture.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
|
|
|
|
|
imho, this "new" Interface is a long way from Fowler and Brooch's classic concept, and "programming to the interface" philosophy.
«The mind is not a vessel to be filled but a fire to be kindled» Plutarch
|
|
|
|
|
Perhaps, but I do find it to be a convenient place to put methods that can be implemented entirely in terms of the rest of the interface.
|
|
|
|
|
BillWoodruff wrote: an abstract class
That wouldn't work for struct s, since they can't have a base class (other than ValueType /Object ).
IIRC, the primary use-case for static members was to allow mathematical operations on generic types. And the vast majority of types you're going to want to use that on will be structs.
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
i'm afraid i missed how 'structs came up, here.
«The mind is not a vessel to be filled but a fire to be kindled» Plutarch
|
|
|
|
|
Generic math - .NET | Microsoft Learn[^]
The majority of types you'd want to perform mathematical operations on are struct s. And you can't have an abstract base class for a struct.
Also, as far as static members go, an abstract base class still wouldn't help; you can't "override" a static member from your base class.
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
Sometimes using an interface makes more sense than using abstract base classes (the good old "I am" or "I can" discussion). And some of these interfaces where of course defined in nuget packages.
This means to add a method or property, you would have to either rename the interface and support both for a while, or you would force anyone who use your nuget package to reimplement the interface. Doable when users only have only a few nuget packages, and the runtime will guard you against a newer version of a package than you expect.
However with the way a lot of software is structured today it does not work anymore. Projects use a lot of nuget packages, and they have internal dependencies meaning updating one nuget package could lead to a chain reaction of having to update others... and sometimes there just was not a way of getting all of them compatible. Basically DLL hell was replaced... by NuGet hell.
Allowing interfaces to add methods/properties and remain backwards compatible makes it easier to write code that will survive when running with newer version of one or another 4th level dependent nuget package than it was written against.
|
|
|
|
|
I am following the online C# tutorials here: create class and objects.
I cannot get the code to envoke the class to create an object. I have some Python knowledge but am learning C#. I am using VS 2022 community edition and running on Windows 10.
I will post the code below but what happens is the Console.WriteLine("Hello, World!"); executes but not the attempt to envoke the class.
I am guessing the code should work like this:
1. C# executable looks for
static void Main(string[] args)
2. Within this main module is the statement:
Person person = new Person();
This line should create an object person.
3. The following lines should assign values to the person object's attributes
person.Name = "Daniel";
person.Age = 28;
person.Haspet = true;
4. The line :
person.Greeting();
should cause the class to be called:
public void Greeting()
{
Console.WriteLine("Within Greeting method. Name is:" + Name +" age is:"+ Age);
Console.ReadLine();
}
but this code does not execute. What am I am getting wrong?
Code:
Console.WriteLine("Hello, World!");
namespace crltemp
{
public class Person
{
public string Name;
public int Age;
public bool Haspet;
public void Greeting()
{
Console.WriteLine("Within Greeting method. Name is:" + Name + " age is:" + Age);
Console.ReadLine();
}
}
class Program
{
static void Main(string[] args)
{
Person person = new Person();
person.Name = "Daniel";
person.Age = 28;
person.Haspet = true;
person.Greeting();
}
}
}
|
|
|
|
|
Quote:
Console.WriteLine("Hello, World!");
namespace crltemp
{
... You've created a project using the new Top-level statements[^] syntax, and forgotten to remove the boilerplate.
As a result, the compiler will generate an entry-point for you which will simply write "Hello, World!" to the console and then exit. The additional Main method in your Program class will never be called.
Remove the code outside of your namespace, and your code should start behaving as expected.
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
Thanks for your very swift reply to a very basic question. Removing the top-level statement meant the compiled program ran as intended.
|
|
|
|
|
Yet another example of Hutber's Law.
|
|
|
|
|
"Hutber's Law". No idea what that meant. Looked it up. Still no idea what it means. I think I've been insulted but I don't know. Play nice.
|
|
|
|
|
My reply was for Richard Deeming, rather than you. But I was alluding to the fact that Microsoft has changed the templates so you don't need to put the main method in a C# Console app, which confuses people because most of the tutorials that you can find will have been created before this "feature" was introduced. And for the record (not an insult to you) Hutber's law - Wikipedia[^].
|
|
|
|
|
They should never have added that "feature" ...
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
I have to extract payment data from PDD's. Some have just one or two lines I need, and other have rows and columns of data.
What's the best way to extract this data using C#?
In theory, theory and practice are the same. But in practice, they never are.”
If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
|
|
|
|
|
Kevin, you've been here long enough; asked enough questions already to know that that's far too vague a query to get anything practical in terms of an answer - all we can do is generically direct you to something like NuGet Gallery | iTextSharp 5.5.13.3[^] and suggest you start there!
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
I was hoping for "I've used...." or "Try this api" kind of answers. I don't have enough info to give more detail because I don't know where to start
In theory, theory and practice are the same. But in practice, they never are.”
If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
|
|
|
|
|
Most people don't use PDFs to transfer data between applications of any kind, so the pool of people who could answer that question is exceedingly small, like none of the regulars around here would have done it.
|
|
|
|
|
If it's a pdf of an image, there's no text either.
There is no "general" solution.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
|
|
|
|