47 Matching Annotations
  1. Jul 2023
    1. approaches, which typically encapsulate bacteria in hydrogels, have produced deployable optical sensors for explosives14, heavy metals15 and chemical inducers16,17
  2. Jun 2023
    1. 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.
    2. When you lose encapsulation, you lose the contract of the declaring class; you cannot guarantee that the class behaves as intended or expected.
    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)
  3. Nov 2021
    1. Abstract the whole queryCommandState / execCommand system into a store (or some wrapper that also holds a store) that has state like isBold and canMakeBold and a makeBold() function.
  4. Jun 2021
    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. But sure, go ahead and enforce self-encapsulation if you like; it makes it easier to do memoization or whatever later on.
    3. Setting an instance variable by going through a setter is good practice, and using two access modifiers is the way to accomplish that for a read-only instance variable
  5. Feb 2021
    1. By reifying a specific kind of computation, a monad not only encapsulates the tedious details of that computational pattern, but it does so in a declarative way, improving the code's clarity.
    1. One of the main reasons to work with components is re-usability and portability, but also a delegation of responsibilities. Adding a component should be as easy as simply adding the component without having to know the inner workings (or markup) of this component. A consumer should only be aware of the properties, methods and events of a component. In order to style a child component one has to be aware of the markup as well, which violates this 'delegation of responsibility'-principle.
    1. The term encapsulation is often used interchangeably with information hiding. Not all agree on the distinctions between the two though; one may think of information hiding as being the principle and encapsulation being the technique. A software module hides information by encapsulating the information into a module or other construct which presents an interface.
    1. I don't see too much gain in moving this to Action Controller beyond the "model layer shouldn't need to be aware of the format that's used to pass the data from the client to the server".
    1. They claim that inheritance often breaks encapsulation, given that inheritance exposes a subclass to the details of its parent's implementation.
    2. Encapsulation is used to hide the values or state of a structured data object inside a class, preventing direct access to them by clients in a way that could expose hidden implementation details or violate state invariance maintained by the methods.
    1. summarizing its significance for the collection;

      Part of what's interesting here is that it isn't necessarily about summarizing each text, as might be done in preparation for a literature review. It allows for more distance from the individual resources. And it's about what makes the collection itself relevant. Since the assessment of resource's relevance has been done, it sounds more like putting the puzzle pieces together and describing the picture which emerges.

      In practice, it's bound to be a cyclical process in many instances. You've built much of the puzzle and find out that you're missing some pieces so you go search for more. And your searches become increasingly directed, like concentric circles.

      This phase in the curation process also sounds like thematic analysis, à la Braun & Clarke, although the collection isn't quite like a corpus. Maybe the two methods are complementary.

  6. Nov 2020
  7. Oct 2020
    1. When I say that my experience is that it means it's time to split up your components, I guess I mean that there tends to be a logical grouping between all the things that care about (for example) sqr_n, and in Svelte, logical groupings are expressed as components.
    1. Derived data can move between being synchronous and asynchronous without modifying the components that use it.
    2. State can be replaced with derived data without modifying the components that use it.
    1. I really missed my data being declarative. By that I mean with Knockout I'd describe a thing and all its behavior in one code block and then I could encapsulate it. React HOCs weren't quite the same. The declarations and the behavior were still separate generally.
  8. Sep 2020
    1. I worry about that being a bit of a Pandora's box — it throws encapsulation completely out the window. The nature of CSS custom properties is that they're inert unless the child chooses to do something with them, which wouldn't be the case for other things.
    2. The problem with working around the current limitations of Svelte style (:global, svelte:head, external styles or various wild card selectors) is that the API is uglier, bigger, harder to explain AND it loses one of the best features of Svelte IMO - contextual style encapsulation. I can understand that CSS classes are a bit uncontrollable, but this type of blocking will just push developers to work around it and create worse solutions.
    1. There is a good amount of properties that should mostly be applied from a parent's point of view. We're talking stuff like grid-area in grid layouts, margin and flex in flex layouts. Even properties like position and and the top/right/left/bottom following it in some cases.
    2. The main reason using classes isn't a great solution is that it completely breaks encapsulation in a confusing way, the paren't shouldn't be dictating anything, the component itself should. The parent can pass things and the child can choose to use them or not but that is different: control is still in the hands of the component itself, not an arbitrary parent.
    3. The RFC is more appropriate because it does not allow a parent to abritrarily control anything below it, that responsibility still relies on the component itself. Just because people have been passing classes round and overriding child styles for years doesn't mean it is a good choice and isn't something we wnat to encourage.
    4. For my point of view, and I've been annoyingly consistent in this for as long as people have been asking for this feature or something like it, style encapsulation is one of the core principles of Svelte's component model and this feature fundamentally breaks that. It would be too easy for people to use this feature and it would definitely get abused removing the style safety that Svelte previously provided.
    1. the notion that any given component should be in charge of its own thing, and not do something outside of itself. I.e., loosely coupled components in a sandbox, not tightly coupled to something outside of its own scope.
    1. This arguably breaks encapsulation (it's not encouraging you to only pass down custom properties, but any styles to an element you don't control), and is contingent on component authors handling it in a consistent way.
    2. I'm personally surprised about that, given the degree to which web component advocates prioritise encapsulation — it seems like a footgun, honestly
    3. Personally, I think class is too blunt an instrument — it breaks encapsulation, allowing component consumers to change styles that they probably shouldn't, while also denying them a predictable interface for targeting individual styles, or setting theme properties globally
    4. ...but ultimately the component itself has control over what is exposed, and can specify its own fallback values using normal CSS custom property syntax:
    1. A component should be in complete control of itself. Not only should a component's styles not leak out but other component's style should never leak in. Consider this 'Encapsulation part 2' if you will. When writing a component, you have certain guarantees that not only will the styles you write be contained within the component, but nothing from the outside should affect you either. You have a certain confidence that if it works in isolation, then it will continue to work when embedded within a complex application.
    2. CSS encapsulation is a critical feature of single file components in Svelte; it allows you to think only about the styles that live together in a given component. Managing CSS has long been one of the more challenging aspects of building for the web; we have no desire to bring those problems back via official APIs that encourage the de-scoping of CSS. We do not wish to revisit the age of namespaced CSS selectors and required preprocessors.
  9. Jan 2019
    1. Grid devices can be nested or layered along with other devices and your plug-ins,

      Thanks to training for Cycling ’74 Max, had a kind of micro-epiphany about encapsulation, a year or so ago. Nesting devices in one another sounds like a convenience but there’s a rather deep effect on workflow when you start arranging things in this way: you don’t have to worry about the internals of a box/patcher/module/device if you really know what you can expect out of it. Though some may take this for granted (after all, other modular systems have had it for quite a while), there’s something profound about getting modules that can include other modules. Especially when some of these are third-party plugins.

  10. Feb 2017