41 Matching Annotations
  1. Mar 2024
  2. Feb 2024
    1. One of my inquiries was for anecdotes regarding mistakes made between the twins by their near relatives. The replies are numerous, but not very varied in character. When the twins are children, they are usually distinguished by ribbons tied round the wrist or neck; nevertheless the one is sometimes fed, physicked, and whipped by mistake for the other, and the description of these little domestic catastrophes was usually given by the mother, in a phraseology that is some- [p. 158] what touching by reason of its seriousness.

  3. Jan 2024
    1. Instance methods Instances of Models are documents. Documents have many of their own built-in instance methods. We may also define our own custom document instance methods. // define a schema const animalSchema = new Schema({ name: String, type: String }, { // Assign a function to the "methods" object of our animalSchema through schema options. // By following this approach, there is no need to create a separate TS type to define the type of the instance functions. methods: { findSimilarTypes(cb) { return mongoose.model('Animal').find({ type: this.type }, cb); } } }); // Or, assign a function to the "methods" object of our animalSchema animalSchema.methods.findSimilarTypes = function(cb) { return mongoose.model('Animal').find({ type: this.type }, cb); }; Now all of our animal instances have a findSimilarTypes method available to them. const Animal = mongoose.model('Animal', animalSchema); const dog = new Animal({ type: 'dog' }); dog.findSimilarTypes((err, dogs) => { console.log(dogs); // woof }); Overwriting a default mongoose document method may lead to unpredictable results. See this for more details. The example above uses the Schema.methods object directly to save an instance method. You can also use the Schema.method() helper as described here. Do not declare methods using ES6 arrow functions (=>). Arrow functions explicitly prevent binding this, so your method will not have access to the document and the above examples will not work.

      Certainly! Let's break down the provided code snippets:

      1. What is it and why is it used?

      In Mongoose, a schema is a blueprint for defining the structure of documents within a collection. When you define a schema, you can also attach methods to it. These methods become instance methods, meaning they are available on the individual documents (instances) created from that schema.

      Instance methods are useful for encapsulating functionality related to a specific document or model instance. They allow you to define custom behavior that can be executed on a specific document. In the given example, the findSimilarTypes method is added to instances of the Animal model, making it easy to find other animals of the same type.

      2. Syntax:

      Using methods object directly in the schema options:

      javascript const animalSchema = new Schema( { name: String, type: String }, { methods: { findSimilarTypes(cb) { return mongoose.model('Animal').find({ type: this.type }, cb); } } } );

      Using methods object directly in the schema:

      javascript animalSchema.methods.findSimilarTypes = function(cb) { return mongoose.model('Animal').find({ type: this.type }, cb); };

      Using Schema.method() helper:

      javascript animalSchema.method('findSimilarTypes', function(cb) { return mongoose.model('Animal').find({ type: this.type }, cb); });

      3. Explanation in Simple Words with Examples:

      Why it's Used:

      Imagine you have a collection of animals in your database, and you want to find other animals of the same type. Instead of writing the same logic repeatedly, you can define a method that can be called on each animal instance to find similar types. This helps in keeping your code DRY (Don't Repeat Yourself) and makes it easier to maintain.

      Example:

      ```javascript const mongoose = require('mongoose'); const { Schema } = mongoose;

      // Define a schema with a custom instance method const animalSchema = new Schema({ name: String, type: String });

      // Add a custom instance method to find similar types animalSchema.methods.findSimilarTypes = function(cb) { return mongoose.model('Animal').find({ type: this.type }, cb); };

      // Create the Animal model using the schema const Animal = mongoose.model('Animal', animalSchema);

      // Create an instance of Animal const dog = new Animal({ type: 'dog', name: 'Buddy' });

      // Use the custom method to find similar types dog.findSimilarTypes((err, similarAnimals) => { console.log(similarAnimals); }); ```

      In this example, findSimilarTypes is a custom instance method added to the Animal schema. When you create an instance of the Animal model (e.g., a dog), you can then call findSimilarTypes on that instance to find other animals with the same type. The method uses the this.type property, which refers to the type of the current animal instance. This allows you to easily reuse the logic for finding similar types across different instances of the Animal model.

      Certainly! Let's go through each part and explain it in simple terms: ### 1. `this` in Mongoose: - **What is `this`?** In JavaScript, `this` refers to the current context or object. In Mongoose, particularly within methods and middleware functions, `this` represents the instance (document) the function is currently operating on. - **Why is it used?** `this` is used to access and modify the properties of the current document. For example, in a Mongoose method, `this` allows you to refer to the fields of the specific document the method is called on. ### 2. Example: Let's use the `userSchema.pre("save", ...)`, which is a Mongoose middleware, as an example: ```javascript userSchema.pre("save", async function (next) { if (!this.isModified("password")) { next(); } else { this.password = await bcrypt.hash(this.password, 10); next(); } }); ``` - **Explanation in Simple Words:** - Imagine you have a system where users can sign up and set their password. - Before saving a new user to the database, you want to ensure that the password is securely encrypted (hashed) using a library like `bcrypt`. - The `userSchema.pre("save", ...)` is a special function that runs automatically before saving a user to the database. - In this function: - `this.isModified("password")`: Checks if the password field of the current user has been changed. - If the password is not modified, it means the user is not updating their password, so it just moves on to the next operation (saving the user). - If the password is modified, it means a new password is set or the existing one is changed. In this case, it uses `bcrypt.hash` to encrypt (hash) the password before saving it to the database. - The use of `this` here is crucial because it allows you to refer to the specific user document that's being saved. It ensures that the correct password is hashed for the current user being processed. In summary, `this` in Mongoose is a way to refer to the current document or instance, and it's commonly used to access and modify the properties of that document, especially in middleware functions like the one demonstrated here for password encryption before saving to the database.

    Tags

    Annotators

    URL

  4. Dec 2023
  5. Nov 2023
  6. Jun 2023
    1. Are protected members/fields really that bad? No. They are way, way worse. As soon as a member is more accessible than private, you are making guarantees to other classes about how that member will behave. Since a field is totally uncontrolled, putting it "out in the wild" opens your class and classes that inherit from or interact with your class to higher bug risk. There is no way to know when a field changes, no way to control who or what changes it. If now, or at some point in the future, any of your code ever depends on a field some certain value, you now have to add validity checks and fallback logic in case it's not the expected value - every place you use it. That's a huge amount of wasted effort when you could've just made it a damn property instead ;) The best way to share information with deriving classes is the read-only property: protected object MyProperty { get; } If you absolutely have to make it read/write, don't. If you really, really have to make it read-write, rethink your design. If you still need it to be read-write, apologize to your colleagues and don't do it again :) A lot of developers believe - and will tell you - that this is overly strict. And it's true that you can get by just fine without being this strict. But taking this approach will help you go from just getting by to remarkably robust software. You'll spend far less time fixing bugs.

      In other words, make the member variable itself private, but can be abstracted (and access provided) via public methods/properties

    2. Public and/or protected fields are bad because they can be manipulated from outside the declaring class without validation; thus they can be said to break the encapsulation principle of object oriented programming.
    3. Using a property or a method to access the field enables you to maintain encapsulation, and fulfill the contract of the declaring class.
    4. Exposing properties gives you a way to hide the implementation. It also allows you to change the implementation without changing the code that uses it (e.g. if you decide to change the way data are stored in the class)
    1. TypeScript offers special syntax for turning a constructor parameter into a class property with the same name and value. These are called parameter properties

      Doesn't this violate their own non-goal #6, "Provide additional runtime functionality", since it emits a this.x = x run-time side effect in the body that isn't explicitly written out in the source code?

  7. Oct 2022
    1. II.-La commission est composée :a) Lorsqu'il s'agit d'une région, de la collectivité territoriale de Corse, d'un département, d'une commune de 3 500 habitants et plus et d'un établissement public, par l'autorité habilitée à signer la convention de délégation de service public ou son représentant, président, et par cinq membres de l'assemblée délibérante élus en son sein à la représentation proportionnelle au plus fort reste ;
  8. Jun 2021
    1. Same feature in TypeScript¶ It's worth mentioning that other languages have a shortcut for assignment var assignment directly from constructor parameters. So it seems especially painful that Ruby, despite being so beautifully elegant and succinct in other areas, still has no such shortcut for this. One of those other languages (CoffeeScript) is dead now, but TypeScript remains very much alive and allows you to write this (REPL): class Foo { constructor(public a:number, public b:number, private c:number) { } } instead of this boilerplate: class Foo { constructor(a, b, c) { this.a = a; this.b = b; this.c = c; } } (The public/private access modifiers actually disappear in the transpiled JavaScript code because it's only the TypeScript compiler that enforces those access modifiers, and it does so at compile time rather than at run time.) Further reading: https://www.typescriptlang.org/docs/handbook/2/classes.html#parameter-properties https://basarat.gitbook.io/typescript/future-javascript/classes#define-using-constructor https://kendaleiv.com/typescript-constructor-assignment-public-and-private-keywords/ I actually wouldn't mind being able to use public/private modifiers on instance var parameters in Ruby, too, but if we did, I would suggest making that be an additional optional shortcut (for defining accessor methods for those instance vars) that builds on top of the instance var assignment parameter syntax described here. (See more detailed proposal in #__.) Accessors are more of a secondary concern to me: we can already define accessors pretty succinctly with attr_accessor and friends. The bigger pain point that I'm much more interested in having a succinct shortcut for is instance var assignment in constructors. initialize(@a, @b, @c) syntax¶ jsc (Justin Collins) wrote in #note-12: jjyr (Jinyang Jiang) wrote: I am surprised this syntax has been repeatedly requested and rejected since 7 years ago. ... As someone who has been writing Ruby for over 10 years, this syntax is exactly that I would like. I grow really tired of writing def initialize(a, b, c) @a = a @b = b @c = c end This would be perfect: def initialize(@a, @b, @c) end I'm a little bit sad Matz is against this syntax, as it seems so natural to me. Me too!! I've been writing Ruby for over 15 years, and this syntax seems like the most obvious, simple, natural, clear, unsurprising, and Ruby-like. I believe it would be readily understood by any Rubyist without any explanation required. Even if you saw it for the first time, I can't think of any way you could miss or misinterpret its meaning: since @a is in the same position as a local variable a would normally be, it seems abundantly clear that instead of assigning to a local variable, we're just assigning to the variable @a instead and of course you can reference the @a variable in the constructor body, too, exactly the same as you could with a local variable a passed as an argument. A workaround pattern¶ In the meantime, I've taken to defining my constructor and list of public accessors (if any) like this: attr_reader \ :a, :b def new( a, b) @a, @b = a, b end ... which is still horrendously boilerplatey and ugly, and probably most of you will hate — but by lining up the duplicated symbols into a table of columns, I like that I can at least more easily see the ugly duplication and cross-check that I've spelled them all correctly and handled them all consistently. :shrug: Please??¶ Almost every time I write a new class in Ruby, I wish for this feature and wonder if we'll ever get it. Can we please?
    1. I've seen (and fixed) Ruby code that needed to be refactored for the client objects to use the accessor rather than the underlying mechanism, even though instance variables aren't directly visible. The underlying mechanism isn't always an instance variable - it can be delegations to or manipulations of a class you're hiding behind a facade, or a session store with a particular format, or all kinds. And it can change. 'Self-encapsulation' can help if you need to swap a technology, a library, an object specification, etc.
    2. a principle I use is: If you have an accessor, use the accessor rather than the raw variable or mechanism it's hiding. The raw variable is the implementation, the accessor is the interface. Should I ignore the interface because I'm internal to the instance? I wouldn't if it was an attr_accessor.
    3. I have been wrapping instance variables in accessor methods whenever I can though.
    4. Also, Sandi Metz mentions this in POODR. As I recall, she also advocates wrapping bare instance variables in methods, even when they're only used internally. It helps avoid mad refactoring later.
    5. in languages (like JavaScript and Java) where external objects do have direct access to instance vars
  9. basarat.gitbook.io basarat.gitbook.io
    1. Having a member in a class and initializing it like below:class Foo { x: number; constructor(x:number) { this.x = x; }}is such a common pattern that TypeScript provides a shorthand where you can prefix the member with an access modifier and it is automatically declared on the class and copied from the constructor. So the previous example can be re-written as (notice public x:number):class Foo { constructor(public x:number) { }}
  10. Mar 2021
  11. Jul 2020
    1. prototype-based,

      "A style of object-oriented programming in which behaviour reuse (known as inheritance) is performed via a process of reusing existing objects that serve as prototypes. This model can also be known as prototypal, prototype-oriented, classless, or instance-based programming."

      https://en.wikipedia.org/wiki/Prototype-based_programming

  12. Jun 2020
  13. Apr 2020
    1. api-version A query string parameter, indicating the API version for the IMDS endpoint. Please use API version 2018-02-01 or greater.

      Couldn't find where the exhaustive list of API versions are listed, but found this on the Azure Instance Metadata Service (aka IMDS) page:

      2017-04-02, 2017-08-01, 2017-12-01, 2018-02-01, 2018-04-02, 2018-10-01, 2019-02-01, 2019-03-11, 2019-04-30, 2019-06-01, 2019-06-04, 2019-08-01, 2019-08-15

      Also:

      The version 2019-11-01 is currently getting deployed and may not be available in all regions.

  14. Jan 2020
  15. Nov 2019
  16. Feb 2019
  17. Jan 2019
  18. Dec 2015
    1. For instance, why are there relatively more tweets referencing zombies in Germany than in France? Is it simply language differences? Or is there a German cultural meme that is conducive to zombies? Or is it population differences such as the presence of US military personnel in Germany who are doing all the zombie tweets? Or perhaps there are simply more zombies in Germany? (Graham, Shelton, and Zook. 2013).