 Oh, this time around, I want to talk about properties. And this will be a very short one, because one of these languages has absolutely nothing to even say other than, that it doesn't have properties. Now in and of itself, I don't think the lack of a feature is necessarily a bad thing if that feature is not justified, or if there is an alternative that is adequate. It's not necessary. Properties I think are justified though, and C-sharp, VB, and F-sharp, they've all got them. In fact, it's becoming such an obviously good thing that tons of languages have them. So first off, what is a property? Essentially, it's a method with a specific name as part of its signature, where one of these will act as a getter, and one of these will act as a center for a backing field that may or may not exist. So, as far as syntax goes for a language that actually defines properties, not a property pattern like Java does, or Eta does, but actual properties, they look exactly like fields. They behave exactly like fields in the superficial sense. And if you're relying on auto-implemented properties with absolutely no details, they are fields. In that instance, it might seem a little weird as to why you'd want to use it in the first place. If it's not a public API, you actually don't want to, but if it's strictly internal implementation details, you'd want to just go with a field. Properties are something that is interesting for public APIs and their maintenance and efficiency and all that jazz. One of the great examples I can give for this is with geometric data types. So, say a triangle. There's numerous things that look like single values that you'd want to store and represent and work with as if they were just those values. You don't want to be concerned with what parts of the triangle the type actually stores. You want it to present all of them as if they are. Of course, you don't want to actually store all of them because that's remarkably inefficient. But let's think about this. Let's think about all the different things that a triangle could store and would need to represent. The length of all three sides, the angle between all three sides. Now that can be done as interior or exterior, depending on exactly what your school of trigonometry is. You'd be doing different things. If you have one, you can easily calculate the other, but typically speaking, people work with interior angles and if you don't expose anything other than that, that would be acceptable, but there are situations where you'd want exterior angles to be surfaced. Typically speaking, if you actually do that, you can just use the interior angles, calculate the exterior angles as you need them because it's easy to do. So that right there. We're already talking six fields. Assuming your angular precision is even halfway decent, that means you're probably using a single or a double floating point, in which case you now have probably three 32-bit integers and three, let's say, worst case, you're using doubles. So you've already got a type that's over 300-bits, over 300-bits, rather large, but we're not actually done yet. See, you're probably not all that interested in just the triangle's existence. You're probably also interested in where it is on a plane. That means point needs to be stored as well. There's three points for where each of the sides meet up, reach vertex. That would also be stored as a double. You now have a type that is easily over 500-bits. Really doesn't need to be. You can calculate basically all of those. You only need four of them. I believe that's the smallest you can do this. If anybody's got a better idea than cool, I don't deal hugely with this kind of stuff. You need the point, you need two sides, and you need one angle. Alternatively, you could do the point and all three sides and calculate the angles from that, but just from experience, you're going to have a little bit better time computationally if you have a point, two sides, and one angle. So that means two points, one side, and two angles are superfluously stored. You do not need to be there. They can be computed on the fly. Think about that. You can, of course, expose just those particular ones through get, side, see, get, angle, be, get, angle, see, and so on. But really, you really want to do that? Similarly, what do you do in instances where you can optimize because of a particular shape of the triangle? A nice Ossoli's triangle is a great example of that. With a nice Ossoli's triangle, you actually only need to store the point and one side. The angles are guaranteed to be a specific measure, but does that mean you expose new layer property patterns for that? How do you call that, assuming you have the base triangle that doesn't work all that well? Is it starting to become a little obvious why the property pattern is actually, or not the property pattern, but actual language support for properties is actually useful? You can make all of these look like their fields, and if you ever change the way that these triangles are actually stored in data, which is certainly possible, people come up with clever optimizations all the time. Maybe for a particular hardware, it's more efficient to store certain other fields and not the ones I mentioned, depending on how efficiently they compute various things. With everything as properties, well, you can do that fairly easily. You can switch those around, and your internals, sure, they're changed, but your public API is exactly the same. It's not like you have to use a get side A method in certain situations, but you just get the A field in others. Now of course, you could just expose literally everything through a get method, because that's ugly. It works. It solves the problem, but holy crap, is it ugly. And of course, it becomes much harder to optimize. See with a property, they're so limited in scope that an optimizer can rightfully make certain assumptions about what the code is actually doing, and it becomes much easier to optimize. That's why an auto-implemented property has no overhead. There is no actual method that is created, so long as it's not virtual. But even then, the JIT can often, after a few runs, optimize it down to just the field call. Properties aren't just useful for this, however. Believe it or not, there are situations where set-only properties are useful. I haven't run into too many, but they do exist. There are situations where that is a justifiable thing. Little experimental project that had going on a few days ago that definitely came up. Sure, you could do it with a method call, but in this situation, because it was essentially setting a pin, virtualization of hardware, setting a pin high rather than low to start the entire thing, as if it, you know, you just connected power. You can't read from that pin. There would... I mean, theoretically you could, but there would never be anything coming out. So it's a set-only property. And sure, I could come up with different ways to actually do that. Instead of exposing that as a pin like it truly is, could just, you know, create a start-up or power-on method that does that kind of behavior, but I was trying to keep everything orthogonal. And like I said, it was an experimental project. It's not like it was some sort of production thing. I just wanted to see how far I could take certain ideas. So properties are useful, and they're definitely something I would like to see in really any language that I'm using. There's something that I wind up missing from it a lot. So like I said, short video, especially since holy crap are some flies trying to eat me up and I've sort of had enough of this, get off of me. So have a good one, guys.