DEV Community: vinaykumar0339

JexLang: Write Once, Validate Everywhere — A Platform-Agnostic Expression Language

vinaykumar0339 — Sat, 13 Dec 2025 18:51:19 +0000

🎯 The Problem We All Face

Picture this: You're building a multi-platform application. A React web app, an Android mobile app, a Spring Boot backend, and maybe an iOS app in the pipeline. Everything seems manageable until you hit a familiar wall — validation logic.

Your product manager walks in and says:

"We need to validate that users are 18+ years old, their email matches the company domain, and if they select 'Premium' plan, they must have a valid credit card."

Simple enough, right? Now multiply that across platforms:

// JavaScript (Web/React Native/NodeJS)
if (user.age >= 18 && user.email.endsWith('@company.com') && 
    (user.plan !== 'Premium' || user.hasValidCard)) {
  // valid
}

// Java (Backend/Android)
if (user.getAge() >= 18 && user.getEmail().endsWith("@company.com") && 
    (!user.getPlan().equals("Premium") || user.hasValidCard())) {
  // valid
}

// Swift (iOS)
if user.age >= 18 && user.email.hasSuffix("@company.com") && 
    (user.plan != "Premium" || user.hasValidCard) {
  // valid
}

Now imagine you have 50+ validation rules across your application. Each platform has its own implementation. Each implementation needs to be tested. Each implementation can have subtle bugs.

Welcome to validation hell. 🔥

😫 The Real Pain Points

1. Code Duplication Nightmare

Every validation rule exists in multiple places. When a business rule changes, you're updating code in 3-4 different repositories. Miss one? Congratulations, you now have inconsistent behavior that will haunt your debugging sessions.

2. Subtle Platform Differences

Each language handles things slightly differently:

String comparison: === vs .equals() vs ==
Null handling: undefined vs null vs Optional<>
Type coercion: JavaScript's quirky "5" + 3 = "53" vs Java's strict typing

These subtle differences lead to bugs that only appear on specific platforms — the worst kind of bugs.

3. Hardcoded Logic = Deployment Pain

Need to change a validation rule? That's a code change. Code change means PR review, testing, staging, and deployment. For each platform. Separately.

What if the validation logic could live in your database or configuration? What if non-developers could modify simple rules without touching code?

4. Testing Overhead

50 validation rules × 4 platforms = 200 test cases (at minimum). And you need to ensure they all behave identically. Good luck with that.

💡 What If There Was a Better Way?

What if you could write your validation logic once in a simple, familiar syntax:

user.age >= 18 && endsWith(user.email, "@company.com") && (user.plan != "Premium" || user.hasValidCard)

And have it execute identically on:

✅ JavaScript/TypeScript (Browser & Node.js)
✅ Java (Android & Backend)
🚧 Swift (iOS) — coming soon!

No platform-specific quirks. No code duplication. No deployment overhead.

This is exactly why I built JexLang.

🚀 Introducing JexLang

JexLang is a lightweight, platform-agnostic expression language with JavaScript-like syntax. It's designed to solve one problem exceptionally well: write logic once, run it everywhere with consistent behavior.

Why JavaScript-Like Syntax?

Let's be honest — most developers are familiar with JavaScript syntax. Even if you're primarily a Java or Swift developer, you've likely encountered JavaScript at some point. By using a familiar syntax, JexLang has virtually zero learning curve.

If you can write this:

user.age >= 18 && user.active === true

You already know JexLang.

🛠️ How JexLang Works

JexLang consists of three core components:

1. Lexer (Tokenizer)

Breaks down your expression into tokens:

"user.age >= 18" → [IDENTIFIER:user, DOT, IDENTIFIER:age, GTE, NUMBER:18]

2. Parser

Converts tokens into an Abstract Syntax Tree (AST):

BinaryExpression {
  left: MemberExpression { object: "user", property: "age" },
  operator: ">=",
  right: NumericLiteral { value: 18 }
}

3. Interpreter

Evaluates the AST against your context data and returns the result.

The magic? The same AST structure and evaluation logic is implemented identically in each language. Same parser rules. Same operator precedence. Same type coercion. Same results.

📖 Real-World Use Cases

1. Dynamic Form Validations

Store validation rules in your backend and share them across all platforms:

{
  "fields": [
    {
      "name": "email",
      "validations": [
        {
          "rule": "required(email)",
          "message": "Email is required"
        },
        {
          "rule": "contains(email, '@')",
          "message": "Please enter a valid email"
        }
      ]
    },
    {
      "name": "age",
      "validations": [
        {
          "rule": "age >= 18",
          "message": "You must be 18 or older"
        }
      ]
    }
  ]
}

Your React app, Android app, and backend all fetch these rules and evaluate them using JexLang. One source of truth.

2. Business Rule Engines

Configure business logic without code deployments:

// Rules stored in database
const discountRules = [
  { condition: "customer.tier == 'Gold' && cart.total > 100", discount: 20 },
  { condition: "customer.tier == 'Silver' && cart.total > 200", discount: 10 },
  { condition: "cart.items.length > 5", discount: 5 }
];

// Evaluate at runtime
const applicableRule = discountRules.find(rule => 
  jexlang.evaluate(rule.condition, { customer, cart })
);

Marketing team wants to change the Gold tier threshold from 100 to 150? Update the database. No deployment needed.

3. Conditional UI Rendering

Show/hide UI elements based on configurable rules:

{
  "component": "PremiumBanner",
  "showWhen": "user.subscription == 'free' && user.daysActive > 30"
}

4. Workflow Automation

Build workflow engines where conditions are user-configurable:

IF order.total > 1000 AND customer.verified === true
  → Route to priority fulfillment

IF order.items.length > 10
  → Apply bulk processing

IF contains(order.shippingAddress.country, 'EU')
  → Apply VAT calculation

5. Feature Flags with Complex Logic

Go beyond simple boolean flags:

const featureRules = {
  "newCheckout": "user.region == 'US' && user.accountAge > 30 && !user.hasActiveIssues",
  "betaFeatures": "user.role == 'developer' || contains(user.email, '@internal.com')"
};

⚡ Quick Examples

Basic Expressions

// Arithmetic
jexlang.evaluate("10 + 5 * 2")  // 20

// Comparisons
jexlang.evaluate("100 >= 50")  // true

// Logical operators
jexlang.evaluate("true && false || true")  // true

// String operations
jexlang.evaluate("'Hello' + ' ' + 'World'")  // "Hello World"

Working with Context

const context = {
  user: {
    name: "John Doe",
    age: 28,
    email: "john@company.com",
    roles: ["admin", "editor"]
  },
  settings: {
    maxUploadSize: 100,
    allowedFormats: ["jpg", "png", "pdf"]
  }
};

// Access nested properties
jexlang.evaluate("user.name", context)  // "John Doe"

// Complex conditions
jexlang.evaluate("user.age >= 18 && contains(user.email, '@company.com')", context)  // true

Built-in Functions

// String functions
jexlang.evaluate("length('Hello')")  // 5
jexlang.evaluate("upper('hello')")  // "HELLO"
jexlang.evaluate("startsWith('Hello World', 'Hello')")  // true

// Array functions
jexlang.evaluate("length(items)", { items: [1, 2, 3] })  // 3

// Type checking
jexlang.evaluate("isNumber(42)")  // true
jexlang.evaluate("isString('hello')")  // true

Ternary Expressions

jexlang.evaluate("user.age >= 18 ? 'Adult' : 'Minor'", { user: { age: 25 } })  // "Adult"

🔧 Getting Started

JavaScript/TypeScript

Installation:

npm install jexlang-ts

Usage:

import { JexEvaluator } from "jexlang-ts";

const jexlang = new JexEvaluator();

// Simple expression
const result = jexlang.evaluate("1 + 2 * 3");  // 7

// With context
const context = { user: { name: "John", age: 30 } };
const isAdult = jexlang.evaluate("user.age >= 18", context);  // true

Java

Gradle:

implementation 'io.github.vinaykumar0339:jexlang-java:1.0.0'

Maven:

<dependency>
    <groupId>io.github.vinaykumar0339</groupId>
    <artifactId>jexlang-java</artifactId>
    <version>1.0.0</version>
</dependency>

Usage:

import io.github.vinaykumar0339.evaluator.JexEvaluator;

JexEvaluator jexlang = new JexEvaluator();

// Simple expression
Object result = jexlang.evaluate("1 + 2 * 3");  // 7

// With context
Map<String, Object> user = Map.of("name", "John", "age", 30);
Map<String, Object> context = Map.of("user", user);
Boolean isAdult = (Boolean) jexlang.evaluate("user.age >= 18", context);  // true

🆚 How JexLang Compares

Feature	JexLang	Hardcoded Logic	JSON Schema	Other Expression Languages
Platform Agnostic	✅ Identical behavior	❌ Platform-specific	⚠️ Library-dependent	⚠️ Mostly single platform
Familiar Syntax	✅ JavaScript-like	✅ Native language	❌ Verbose JSON	⚠️ Varies (SpEL, OGNL, etc.)
Runtime Configurable	✅	❌	✅	✅
Complex Logic Support	✅	✅	❌ Limited	✅
Learning Curve	🟢 Low (JS developers)	🟢 None	🟡 Medium	🟡 Medium to High
Consistent Cross-Platform	✅ Same AST/Interpreter	❌	⚠️ Validator differences	❌ Usually single platform
Custom Functions	✅	✅	❌	✅
Transforms/Pipes	✅ `value \ transform`	⚠️ Manual	❌	⚠️ Rare

🗺️ Roadmap

Platform	Status	Use Cases
JavaScript/TypeScript	✅ Production Ready	Browser apps, Node.js APIs, no-code/low-code rule engines
Java	✅ Production Ready	Android apps, backend services, enterprise rule engines
Swift	🚧 In Progress	iOS apps, macOS automation, workflow logic

Future considerations:

Python support

🙏 Call to Action

JexLang is open source and in its early days. I've built it to solve real problems I've faced, but I know the community will find use cases I never imagined.

Here's how you can help:

⭐ Star the repository — It helps with visibility and motivates continued development.
🧪 Try it in your projects — Put it through real-world scenarios and see how it holds up.
🐛 Report issues — Found a bug? Edge case that doesn't work? Let me know!
💡 Suggest features — What would make JexLang more useful for your use case?
📢 Share with your network — Know someone who might benefit? Spread the word!

📚 Resources

Resource	Link
GitHub Repository	https://github.com/vinaykumar0339/jexlang
NPM Package	https://www.npmjs.com/package/jexlang-ts
Maven Repository	https://mvnrepository.com/artifact/io.github.vinaykumar0339/jexlang-java
Language Reference	https://github.com/vinaykumar0339/jexlang/blob/main/docs/language-reference.md
Report Issues	https://github.com/vinaykumar0339/jexlang/issues

🎬 Final Thoughts

Cross-platform development is hard enough without having to maintain identical logic in multiple languages. JexLang aims to eliminate that pain point by providing a single, consistent way to express logic that works everywhere.

Whether you're building form validations, business rule engines, workflow automation, or config-driven applications, JexLang gives you the power to write once and run everywhere.

I'm excited to see what you build with it.

Have questions or feedback? Drop a comment below or reach out on GitHub. I'd love to hear from you!

#OpenSource #JavaScript #TypeScript #Java #Swift #ExpressionLanguage #FormValidation #CrossPlatform #DeveloperTools #Programming

DataStructures In Computer Science - Introduction

vinaykumar0339 — Sun, 21 Jul 2024 06:35:49 +0000

What are Data Structures

A data structure is a specialized format for organizing, processing, retrieving and storing data.
Well-designed data structures enable efficient data access and modification, enhancing performance for various algorithms and applications.
They are fundamental to computer science and software engineering, allowing developers to manage and manipulate large amounts of data effectively.

Different Types of Data Structures

Data Structures can be broadly classified into two categories.

Linear Data Structures

Arrays
LinkedList
Stack
Queues

Non-Linear Data Structures

Tress (Binary Trees, Binary Search Trees, AVL Trees etc)
Heaps
Graphs
Tries

self vs Self in Swift Programming

vinaykumar0339 — Sat, 13 Jul 2024 15:26:29 +0000

In Swift, self and Self (with a capital 'S') play distinct roles in object-oriented and protocol-oriented programming. They are crucial keywords that ensure clarity, type safety, and facilitate various coding patterns. Let’s dive into their meanings, differences, and practical applications

self

self refers to a class or struct's current instance (object). It distinguishes instance variables or methods from local variables or parameters.

Self

Self (with a capital 'S') refers to the current type itself. It is beneficial in protocols and generic contexts to ensure type safety and clarity.

Example

class Person {
    private var name: String
    private var age: Int

    init(name: String, age: Int) {
        self.name = name
        self.age = age
    }

    func updateAgeWithExactClassType(age: Int) -> Person {
        self.age = age
        return self
    }

    func updateAgeWithSelfKeyword(age: Int) -> Self {
        self.age = age
        return self
    }
}

let person = Person(name: "vinay", age: 26)

person.updateAgeWithExactClassType(age: 30)

person.updateAgeWithSelfKeyword(age: 40)

In the Person class example above, self is used to refer to the current instance of the class when accessing its properties or methods. Which uses to differ method parameters from instance variables
The updateAgeWithSelfKeyword method uses Self as its return type. This allows the method to return an instance of the same class type (Person) or its subclass dynamically, which is useful for method chaining and adhering to the builder pattern

Benefits of `Self` over exact Class `Person` as return type

Drawbacks of `updateAgeWithExactClassType`

The updateAgeWithExactClassType method explicitly returns Person, which limits its usage when subclassing Person. If you subclass Person, you cannot override this method to return instances of the subclass without changing its return type.

Advantages of `updateAgeWithSelfKeyword`

The updateAgeWithSelfKeyword method uses Self as its return type. This means it dynamically resolves to the type of the current instance (Person or its subclass). You can override this method in subclasses and have it return instances of those subclasses, maintaining type safety and adhering to the builder pattern.

To understand more let's change the code snippet a little bit.

class AdvancedPerson: Person {

    func extraFunctionality() {
        print("person has super power like avengers")
    }

    override func updateAgeWithExactClassType(age: Int) -> Person {
        // some code
        return self
    }

    override func updateAgeWithSelfKeyword(age: Int) -> Self {
        // some code
        return self
    }
}

let advancedPerson = AdvancedPerson(name: "IronMan", age: 40)
advancedPerson.updateAgeWithExactClassType(age: 50)
advancedPerson.updateAgeWithSelfKeyword(age: 50)

updateAgeWithExactClassType returns Person as a type which won't have functionalities of the sub-class AdvancedPerson we can't be chaining to access methods of the AdvancedPerson class.

updateAgeWithSelfKeyword returns Self on runtime Swift knows what type should return so that we can access existing functionalities of the sub-class AdvancedPerson

Use of `Self` with protocols

protocol Address {
    func addAddress(address: String) -> Self
}

class PersonWithAddress: Person, Address {
    private var address: String?

    func addAddress(address: String) -> Self {
        self.address = address
        return self
    }
}

let personWithAddress = PersonWithAddress(name: "vinay", age: 26)
personWithAddress.addAddress(address: "India")

Benefits

self

Clarity: Helps distinguish between instance properties and local variables or parameters within methods.
Avoiding Name Conflicts: Ensures clear referencing of instance properties and methods.

Self

Type Safety: Guarantees that protocols and generics return or reference the exact type of the conforming or implementing instance.
Flexibility: Supports method chaining and builder pattern, improving code readability and maintainability. Using Self allows for returning the exact type without explicitly specifying it, promoting easier code maintenance and adaptation.

Conclusion

Understanding the distinctions between self and Self is crucial for writing clear, type-safe, and maintainable Swift code. While self refers to the current instance, Self ensures consistency in types within protocols and generics. Leveraging these keywords effectively enhances your ability to design robust Swift solutions.

self -> Refers to the current instance (object).
Self -> Refers to the type itself, ensuring type safety and clarity. It simplifies method chaining and conforms to protocols in a flexible manner, improving code maintainability.

swift playground page

PO vs P vs V in LLDB of Xcode

vinaykumar0339 — Thu, 11 Jul 2024 17:09:31 +0000

What is LLDB?

LLDB is Xcode's integrated low-level debugger, essential for examining and debugging applications across Apple's platforms. It enables developers to set breakpoints, inspect variables, and navigate through code execution to diagnose and resolve issues efficiently. With support for both graphical and command-line interfaces, LLDB streamlines debugging workflows from simple variable checks to complex debugging tasks

How to Interact with LLDB?

LLDB allows different ways to interact with the application. such as po, p and v

Let's take a look at below code Snippet.

import Foundation

enum ClassName {
    case c1;
    case c2;
    case c3;
}

class Person {
    var name: String
    var age: Int

    init(name: String, age: Int) {
        self.name = name
        self.age = age
    }

    func setName(name: String) {
        self.name = name
    }
}

class Student: Person {

    var className: ClassName

    init(name: String, age: Int, className: ClassName) {
        self.className = className
        super.init(name: name, age: age)
    }
}

let student = Student(name: "vinay", age: 26, className: .c1)

struct StudentStruct {
    let name: String
    let age: Int
}

let studentStruct = StudentStruct(name: "vinayStruct", age: 26)

What is po?

In Xcode, po stands for "print object," which is used to print the description of an object during debugging. When you use po followed by a variable name in the debugger console, it displays detailed information about that object.

For example, if you want to print the variable student, executing po student in the debugger console will display the object's description or address.

po student

For a variable like studentStruct, which is a struct type and already provides a default debugDescription method, po calls this method to show the detailed description of the object.

po studentStruct

If you confirm the Student class to CustomDebugStringConvertible and override its debugDescription method as shown below:

class Student: Person, CustomDebugStringConvertible {
    var debugDescription: String {
        return "Student(\(self.name), \(self.age))"
    }

    var className: ClassName

    init(name: String, age: Int, className: ClassName) {
        self.className = className
        super.init(name: name, age: age)
    }
}

let student = Student(name: "vinay", age: 26, className: .c1)

By implementing CustomDebugStringConvertible, you provide a custom implementation for the debugDescription property. When you use po student in the debugger console in Xcode, it automatically uses this custom debugDescription method to print a formatted description of the student object, incorporating its name, age, and any other relevant properties or state.

This demonstration clearly illustrates that po is utilized to display the object's description while debugging.

That's all po does? no, It can do more. you can even call the string methods on the name variable of the student

po student.name.uppercased()

In general, It can evaluate any arbitrary expression.

In fact, po is alias for the command expression.

example:

expression --object-description -- student

you can even create your own po commands

command alias my_po expression --object-description --
my_po student

To unalias the created one use below command

command unalias my_po

What is p?

This is a second way of printing a variable in LLDB. You can think it as print without object description.

p student

The representation differs slightly from the one provided by po. But it is equivalent as it gives the same information about the instance variables
p is an alias for the command expression but without --object-description flag
This p gives an incremental name to the result like $R0, $R1 etc.
p uses DataFormatters to print the information. Anyway, we are not covering DataFormatters in this tutorial.

If you use p in the latest Xcode version variables ex: $R0 name is not showing. But it is showing if you're using the expression command. I am not sure why.

What is v?

To understand v, declare a variable studentWithBaseType as Person, not Student.

let studentWithBaseType: Person = Student(name: "vinaywithbasetype", age: 26, className: .c1)

Since studentWithBaseType is of type Person, you cannot read properties specific to Student without casting it first, like accessing className on studentWithBaseType, which Swift's compiler does not allow. To read it, you must cast it:

(studentWithBaseType as! Student).className

Similarly, LLDB dynamically resolves variable types only in expressions. Attempting to access properties directly on the result in LLDB results in an error, as shown below:

But By using v you can read the variables of the actual type Student in the LLDB console

v studentWithBaseType.className

Differences

po (print object):

Use: Print detailed object descriptions during debugging, especially useful for custom debug descriptions (CustomDebugStringConvertible).
When to Use: Use po when you need a formatted and detailed view of an object's state, including custom debug descriptions.

p (print):

Use: Provides basic information about variables and objects without the detailed object description.
When to Use: Use p for quick checks on variable values or when detailed object description isn't necessary, providing a concise view of the variable's state.

v (dynamic resolution):

Use: Used for dynamically resolving types in LLDB expressions, essential when dealing with base types containing more specific class types.
When to Use: Use v to dynamically resolve and access properties specific to a subclass or more detailed class type within LLDB expressions.

Conclusion:

LLDB in Xcode offers powerful tools (po, p, v) for developers to debug applications comprehensively, from simple variable checks to complex debugging tasks, improving overall code quality and performance

for in-depth understanding refer this Apple World Wide Developer Conference - WWDC2019 Resouce

Introduction to GCD (Grand Central Dispatch)

vinaykumar0339 — Wed, 10 Jul 2024 16:35:46 +0000

Apple Dispatch Framework

Dispatch: Execute code concurrently on multicore hardware by submitting work to dispatch queues managed by the system.

Dispatch is also known as Grand Central Dispatch (GCD).
GCD is a queue-based API that allows executing closures on worker's pools in First-In-First-Out (FIFO) Order.

What is GCD?

GCD manages the threads on which tasks are executed, relieving the developer of this responsibility, and ensuring tasks are run on the appropriate dispatch queue.
It is an abstraction layer on the queue.
GCD manages the collection of dispatch queues. The system executes the work submitted to those dispatch queues on the thread pool (worked tool).
GCD can execute the work in serially or concurrently. But always in FIFO Order.

How Work is submitted to DispatchQueue.

Work can be submitted using block of code or Closures.
It can be done by Synchronously or Asynchronously.
Don't be confused between Serially or Concurrently and Synchronously or Asynchronously will explain them in short.

Serially or Concurrently vs Synchronously or Asynchronously

Serially: one task at a time while dispatching the work to the threads pool.

Concurrently: multiple tasks at a time while dispatching the work to the threads pool but in FIFO Order from the Dispatch Queue.

Synchronously: Which blocks the current thread till it completes the task.

Asynchronously: Which will not block the current thread and execute the task separately.

Serially/Concurrently affects the DispatchQueue to which you're dispatching...
Synchronously/Asynchronously affects the current thread from which you are dispatching...

Will see now how to dispatch a block of work into Queue using DispatchQueue.main

There is one main Thread DispatchQueue for an App which is DispatchQueue.main
In Ios main DispatchQueue is sereial queue by default.

Dispatch an work using Asynchronous.

import Foundation
import PlaygroundSupport

PlaygroundPage.current.needsIndefiniteExecution = true

// Which will be dispatching the block of code in asynchronous which will not block the current thread.
DispatchQueue.main.async {
    for i in 0...4 {
        print("DispatchQueue.main async first block \(i)")
    }
}

for i in 5...8 {
    print("normal file execution \(i)")
}

DispatchQueue.main.async {
    print("DispatchQueue.main async second block")
}

// Output.
// normal file execution 5
// normal file execution 6
// normal file execution 7
// normal file execution 8
// DispatchQueue.main async first block 0
// DispatchQueue.main async first block 1
// DispatchQueue.main async first block 2
// DispatchQueue.main async first block 3
// DispatchQueue.main async first block 4
// DispatchQueue.main async second block

Explanation for the above code

1) 5, 6, 7, 8 will be print first because we are dispatching the code in asynchorous manner so main code execution will not be blocked.
2) 0, 1, 2, 3, 4 will be print next because there is no any other code to run in the current thread. so it start executing the async code because DispatchQueue.main is serial queue so it start printing DispatchQueue.main async first block \(i) and then DispatchQueue.main async second block

Benifits of using GCD Over Plain Threads Api

Abstraction of Complexity:

GCD abstracts away the complexities of managing threads directly.
You work with queues and tasks, making it easier to manage concurrency.

Efficient Resource Management:

GCD manages a pool of threads internally by taking most of the developer works for managing resources.
Reduces overhead from thread creation and destruction, optimizing performance

Quality of Service (QoS) Support: (Will talk about this in depth in upcoming posts)

Supports QoS attributes (e.g., background, utility, user-initiated) to prioritize tasks
Adapts dynamically to system load, ensuring optimal task scheduling

Conclusion

In summary, GCD simplifies concurrency management by abstracting thread handling, optimizing resource usage, ensuring safety, promoting asynchronous execution, and integrating well with Swift's ecosystem. It remains a preferred choice for efficient and scalable concurrent programming in iOS, macOS, and beyond

Achieving multi-threading by creating threads manually in Swift

vinaykumar0339 — Tue, 09 Jul 2024 05:51:22 +0000

What is Threading?

Threading is a fundamental concept in programming that allows for the concurrent execution of code. By using multiple threads, you can perform multiple tasks simultaneously, improving the efficiency and performance of your application.

Why Use Threading?

Improved Performance: Execute multiple operations in parallel.
Responsiveness: Keep your application responsive by performing long-running tasks in the background.
Resource Utilization: Make better use of system resources by distributing workloads.

Thread API in Swift

Thread will be available in the Foundation framework

import Foundation

class CustomThread {
    func createThreadUsingObjSelector() {
        let thread = Thread(target: self, selector: #selector(threadExecutor), object: nil)
        thread.start()
    }

    @objc private func threadExecutor() {
        print("Executing threadExecutor \(Thread.current)")
    }

    func createThreadUsingTrailingClosures() {
        let thread = Thread {
            print("Executing createThreadUsingTrailingClosures \(Thread.current)")
        }
        thread.start()
    }
}

let customThread = CustomThread()
customThread.createThreadUsingObjSelector()
customThread.createThreadUsingTrailingClosures()

Pros of using Manual Threads

Fine-Grained Control: You have complete control over thread creation, management, and execution (like start, cancel etc)
Customization: You can customize thread behaviour to suit specific needs.

Crons of using Manual Threads

Resource Intensive: Creating and managing many threads can be resource-intensive and may degrade performance if not managed properly.
Scalability: Manual threading may not scale well with the increasing complexity of applications.
More Power comes with higher responsibility.
Improper management may cause memory leaks in the app.
Managing Order of Execution.

Conclusion

Threading is a powerful tool for improving the performance and responsiveness of your applications. While manual threading provides fine-grained control, it comes with complexity and potential pitfalls. By understanding the pros and cons, and following best practices, you can effectively utilize threading in your Swift applications.

<-- Swift Concurrency -->Introduction to GCD

Swift Concurrency

vinaykumar0339 — Tue, 09 Jul 2024 05:40:23 +0000

What is Concurrency?

In Real Life:

Concurrency in real life refers to the ability to handle multiple activities simultaneously within a given timeframe. This can be seen in various scenarios where multiple tasks are being managed simultaneously.

Examples:

Chef in a Kitchen: A chef might prepare several dishes simultaneously. While one dish is baking in the oven, the chef can chop vegetables for another dish. This is the concurrent execution of tasks.
Office Work: An employee might be handling emails, answering phone calls, and attending daily meetings. These tasks overlap in time, demonstrating concurrency.
Traffic Management: Traffic lights at an intersection manage the flow of cars from different directions. While cars move in one direction, others wait, and pedestrians might cross the street, all managed concurrently.

In Programming:

In programming, concurrency refers to the execution of multiple tasks or processes simultaneously, potentially overlapping in execution time. It is a way to structure a program to do multiple things at once, improving efficiency and performance.

Examples:

Multithreading: Running multiple threads within a single application. Each thread can perform a different task, such as fetching data from the network, processing user input, and updating the user interface.
Asynchronous Programming: Using constructs like async/await to perform non-blocking operations. For instance, fetching data from a server while allowing the user interface to remain responsive.
Parallel Processing: Executing multiple processes or computations simultaneously, often on different CPU cores. This is common in scientific computing, image processing, and machine learning tasks.

What is Parallelism?

In Real Life:

Parallelism in real life refers to the simultaneous execution of multiple tasks by multiple resources. It involves doing multiple things at the same time.

Examples:

Construction Site: Workers on a construction site performing different tasks simultaneously, such as one worker laying bricks while another installs windows.
Orchestra: Different musicians play their instruments at the same time to create a symphony.
Restaurant: Multiple chefs in a restaurant kitchen cooking different dishes at the same time, each using different equipment

Programming:

In programming, parallelism refers to the simultaneous execution of multiple computations or processes. It typically involves dividing a task into subtasks that can be processed concurrently on multiple processors or cores.

Examples:

Parallel Processing: Running multiple computations simultaneously on different CPU cores to speed up processing time.
Parallel Algorithms: Algorithms that divide a problem into subproblems that can be solved concurrently, like matrix multiplication or sorting algorithms.
Distributed Systems: Multiple servers processing different parts of a task at the same time to handle large-scale computations, such as in data centres or cloud computing

Concurrency vs Parallelism?

Concurrency: Two queues share one vending machine, serving one person at a time by alternating between queues.
Parallelism: Each queue has its vending machine, allowing both queues to be served simultaneously.

Parallelism Will give more speed but it involves more CPU resources.

Because Parallelism involves more resources we need to find a way that Concurrency can be achieved.

How Can We Achieve Concurrency in iOS?

Achieving multi-threading by creating threads manually
GCD (Grand Central Dispatch)
Operation Queues
Modern Concurrency By Swift. (async and await)

#5 Dependency Inversion Principle ['D' in SOLID]

vinaykumar0339 — Mon, 01 Jul 2024 17:30:40 +0000

DIP - Dependency Inversion principle
The Dependency Inversion Principle is the fifth principle in the Solid Design Principles.

High-Level Modules should not depend on Low-Level Modules. Both Should depend on abstraction.
Abstraction should not depend on details. Details should depend on Abstraction.

High-Level Modules.

The High-Level Module contains important policy decisions and business logic.
They Should not be affected by changes in Low-Level Modules.

Low-Level Modules.

Low-Level Modules contains implementation details.
Changes in Low-Level Modules should not affect High-Level Modules.

Abstractions

Use Interfaces or Abstraction class to create an abstraction Layer.
High-level modules depend on this abstraction, allowing low-level module changes without affecting high-level logic.

Violating DIP:

class FileLogger {
    func log(message: String) {
        print("Loggin Message to file: \(message)")
    }
}

class UserService {
    private let logger = FileLogger()

    func createUser(name: String) {
        logger.log(message: "User \(name) Created.")
    }
}

// usage
let userService = UserService()
userService.createUser(name: "Vinay Kumar")

Issues with Violating DIP:

Tight Coupling:
- UserService is tightly coupled to FileLogger, making it difficult to change the logging mechanism without modifying UserService.
Reduced Flexibility:
- Switching to a different logging method (e.g., database logger, cloud logger) requires changing UserService.
Hard to Test:
- Testing UserService requires an actual FileLogger, making it harder to isolate and test.

Adhering to DIP:
Using Protocol We can adhere to DIP.

protocol Logger {
    func log(message: String)
}

class FileLoggerDIP: Logger {
    func log(message: String) {
        print("Logging message to file: \(message)")
    }
}

class ConsoleLogger: Logger {
    func log(message: String) {
        print("Logging message to console: \(message)")
    }
}

class UserServiceDIP {
    let logger: Logger

    init(logger: Logger) {
        self.logger = logger
    }

    func createUser(name: String) {
        self.logger.log(message: "User \(name) Created")
    }
}

// usage
let fileLoggerDIP = FileLoggerDIP()
let consoleLogger = ConsoleLogger()
let userServiceDIPUsingFileLogger = UserServiceDIP(logger: fileLoggerDIP)
let userServiceDIPUsingConsoleLogger = UserServiceDIP(logger: consoleLogger)

userServiceDIPUsingFileLogger.createUser(name: "Vinay Kumar DIP FileLogger")
userServiceDIPUsingConsoleLogger.createUser(name: "Vinay Kumar DIP ConsoleLogger")

Benefits of Adhering to DIP:

Improved Maintainability:
- Changes in low-level modules (like FileLogger) do not affect high-level modules (like UserService).
Enhanced Flexibility:
- Easily switch between different logging mechanisms without changing the high-level module.
Increased Testability:
- High-level modules can be tested with mock implementations of abstractions.

Drawbacks of Adhering to DIP:

Increased Complexity:
- Requires creating additional interfaces or abstract classes.
More Boilerplate Code:
- More code is needed to set up the abstractions.

Mitigating Drawbacks:

Balanced Approach:
- Apply DIP where it provides significant benefits, balancing simplicity and extensibility.
Clear Documentation:
- Maintain clear documentation to help developers understand the dependencies.
Use of Dependency Injection Frameworks:
- Use frameworks to manage dependencies efficiently.

Conclusion:
You can create more maintainable, understandable, and flexible software by thoughtfully understanding and applying the Dependency Inversion Principle. Ensuring that high-level modules depend on abstractions rather than low-level details promotes better software design and enhances the overall quality of the codebase.

Interface Segregation Principle
Single Responsibility Principle
Check My GitHub Swift Playground Repo.

#4 Interface Segregation Principle ['I' in SOLID]

vinaykumar0339 — Sun, 30 Jun 2024 18:15:55 +0000

ISP - Interface Segregation Principle

The Interface Segregation Principle is the fourth principle in the Solid Design Principles.

Clients should not be forced to depend on interfaces they do not use.

Violating ISP:

protocol Worker {
    func eat()
    func work()
}

class HumanWorker: Worker {
    func eat() {
        print("Human is eating...")
    }

    func work() {
        print("Human is working...")
    }
}

class RobotWorker: Worker {
    func work() {
        print("Robot is working...")
    }

    func eat() {
        fatalError("Robot can't eat...")
    }
}

// usage
let robot = RobotWorker()
robot.eat()  // This will cause a runtime error

Issues with Violating ISP:

Unnecessary Methods:
- Classes are forced to implement methods they do not use, leading to potential runtime errors.
Increased Complexity:
- Interfaces become bloated with methods irrelevant to some implementations.
Reduced Maintainability:
- Changes to interfaces affect all implementing classes, even if they do not use the changed methods.

Adhering to ISP
To adhere to ISP, separate the protocol into small pieces:

protocol Workable {
    func work()
}

protocol Eatable {
    func eat()
}

protocol WorkerISP: Workable, Eatable {}

class HumanWorkerISP: WorkerISP {
    func eat() {
        print("HumanWorkerISP is eating...")
    }

    func work() {
        print("HumanWorkerISP is working...")
    }
}

class RobotWorkerISP: Workable {
    func work() {
        print("RobotWorkerISP is eating...")
    }
}

// usage
let humanWorker = HumanWorkerISP()
humanWorker.eat()
humanWorker.work()

let robotWorker = RobotWorkerISP()
robotWorker.work()

Benefits of Adhering to ISP:

Improved Maintainability:
- Smaller, specific interfaces are easier to understand and maintain.
Enhanced Flexibility:
- Changes to an interface do not affect clients that do not use that part of the interface.
Increased Reusability:
- Specific interfaces can be reused more easily across different parts of the application.

Drawbacks of Adhering to ISP:

More Interfaces:
- Can lead to an increase in the number of interfaces, making the codebase larger.
Initial Complexity:
- Designing multiple specific interfaces may require more detailed planning and initial effort.

Mitigating Drawbacks:

Balanced Approach:
- Apply ISP judiciously, balancing between simplicity and the need for specificity.
Clear Documentation:
- Maintain clear and concise documentation to help developers understand the purpose of each interface.
Use of Design Patterns:
- Employ design patterns that naturally adhere to ISP, such as the Adapter pattern, to manage complexity.

Conclusion:
By thoughtfully understanding and applying the Interface Segregation Principle, you can create more maintainable, understandable, and flexible software. Ensuring that clients only depend on the interfaces they use promotes better software design and enhances the overall quality of the codebase.

Liskov Substitution Principle
Dependency Inversion Principle
Check My GitHub Swift Playground Repo.

#3 Liskov Substitution Principle ['L' in SOLID]

vinaykumar0339 — Sun, 30 Jun 2024 16:40:59 +0000

LSP - Liskov Substitution Principle
The Liskov Substitution Principle is the third principle in the Solid Design Principles.

Objects of the Super-Class should be replaceable with objects of a Sub-Class without affecting the correctness of the program.

Violating LSP:

class Bird {
    func fly() {
        print("Bird is Flying...")
    }
}

class Duck: Bird {
    override func fly() {
        print("Duck is Flying...")
    }
}

class Ostrich: Bird {
    //we will not be implementing this function in Ostrich because it does not make sense to add this function as Ostrich can't fly. so for demenstrate purposes keep this code with fatalError.
    override func fly() {
        fatalError("Ostrich doesn't fly so behaviour of the application going to change if we pass Ostrich Object to any function which having contract to Bird")
    }
}

func flyBird(bird: Bird) {
    bird.fly()
}

// usage
let bird = Bird()
let duckBird = Duck()
let ostrichBird = Ostrich()
flyBird(bird: bird)
flyBird(bird: duckBird)
flyBird(bird: ostrichBird)

Issues with Violating LSP:

Unexpected Behavior:
- Subclasses that change the expected behaviour of the base class can lead to runtime errors and bugs.
Reduced Maintainability:
- Modifying subclasses to fix LSP violations can make the code harder to maintain.
Inconsistent Substitution:
- Clients using the base class might not work correctly with all subclasses, leading to inconsistent behaviour.

Adhering to LSP

To adhere to LSP, Using Proper Inheritance, or using protocols etc.

Using Class Separation

class BirdLSP {
    func eat() {
        print("Bird is eating...")
    }
}

class FlyingBird: BirdLSP {
    func fly() {
        print("FlyingBird is flying...")
    }
}

class DuckLSP: FlyingBird {
    override func fly() {
        print("Duck is flying...")
    }
}

class OstrichLSP: BirdLSP {
    override func eat() {
        print("Ostrich eating...")
    }
}

func flyBirdLSP(flyingBird: FlyingBird) {
    flyingBird.fly()
}

// usage
let birdLsp = BirdLSP()
let flyingBirdLSP = FlyingBird()
let duckLSP = DuckLSP()
let ostrichLSP = OstrichLSP()

flyBirdLSP(flyingBird: flyingBirdLSP)
flyBirdLSP(flyingBird: duckLSP)

//The below example will throw an error at compile time
// flyBirdLSP(flyingBird: birdLsp)
// flyBirdLSP(flyingBird: ostrichLSP)

Using Protocol

protocol Eatable {
    func eat()
}
protocol Flyable {
    func fly()
}

class BirdLSPUsingProtocol: Eatable {
    func eat() {
        print("BirdLSPUsingProtocol is eating")
    }
}

class DuckLSPUsingProtocol: Eatable, Flyable {
    func eat() {
        print("DuckLSPUsingProtocol is eating")
    }

    func fly() {
        print("DuckLSPUsingProtocol is flying")
    }
}

class OstrichLSPUsingProtocol: Eatable {
    func eat() {
        print("OstrichLSPUsingProtocol is eating")
    }
}

func flyingBirdLSPUsingProtocol(flyer: Flyable) {
    flyer.fly()
}

// usage
let birdLSPUsingProtocol = BirdLSPUsingProtocol()
let duckLSPUsingProtocol = DuckLSPUsingProtocol()
let ostrichLSPUsingProtocol = OstrichLSPUsingProtocol()


flyingBirdLSPUsingProtocol(flyer: duckLSPUsingProtocol)

// below will throw an error on the compile time
// flyingBirdLSPUsingProtocol(flyer: birdLSPUsingProtocol)
// flyingBirdLSPUsingProtocol(flyer: ostrichLSPUsingProtocol)

Benefits of Adhering to LSP:

Improved Maintainability:
- Ensures that derived classes can be used interchangeably with base classes without unexpected behaviour.
Enhanced Flexibility:
- Encourages the use of polymorphism, allowing more flexible and scalable code.
Increased Reliability:
- Substitutable objects ensure consistent behaviour, reducing the likelihood of runtime errors.

Drawbacks of Adhering to LSP:

More Classes and Interfaces:
- Can lead to an increase in the number of classes and interfaces, making the codebase larger.
Initial Complexity:
- Implementing LSP correctly may require a more complex initial design and detailed planning.

Mitigating Drawbacks:

Balanced Approach:
- Apply LSP judiciously, balancing between simplicity and the need for extensibility.
Clear Documentation:
- Maintain clear and concise documentation to help developers understand class hierarchies and responsibilities.
Use of Design Patterns:
- Employ design patterns that naturally adhere to LSP, such as the Strategy pattern, to manage complexity.

Conclusion:

By thoughtfully understanding and applying the Liskov Substitution Principle, you can create more maintainable, understandable, and reliable software. Ensuring that subclasses can be substituted for their superclasses without altering the program's correctness promotes better software design and flexibility.

Open/Close Principle
Interface Segregation Principle
Check My GitHub Swift Playground Repo.

#2 Open Close Principle ['O' in SOLID]

vinaykumar0339 — Sun, 30 Jun 2024 13:19:55 +0000

OCP - Open/Close Principle
The Open/Close Principle is the second principle in the Solid Design Principle.

Software entities should be open for extension but closed for modification.

Today Will discuss about discount calculator system.

Violating OCP:

enum DiscountType {
    case seasonal
    case loyalty
    case nodiscount
}

class DiscountCalculator {
    func calculateDiscount(discountType: DiscountType, amount: Double) -> Double {
        switch discountType {
        case .seasonal:
            return amount * 0.1
        case .loyalty:
            return amount * 0.15
        case .nodiscount:
            return 0
//        Including a default case can handle unexpected cases but won't prompt Xcode to show an error or warning if a new DiscountType is added later. This means new cases could be missed without any compile-time notifications.
        default:
            return 0
        }
    }
}

// usage
let discountCalcualtor = DiscountCalculator()
discountCalcualtor.calculateDiscount(discountType: .seasonal, amount: 100)
discountCalcualtor.calculateDiscount(discountType: .loyalty, amount: 100)
discountCalcualtor.calculateDiscount(discountType: .nodiscount, amount: 100)

Issues with Violating OCP:

Hard to Extend:
- Adding a new discount required modification of the function calculateDiscount.
Increase Complexity:
- calculateDiscount becomes complex with multiple discount types.
Difficult Maintenance:
- Changes in discount logic require updates to calculateDiscount.

Adhering to OCP:
To Adhere to OCP, Use Protocol to confirm the contract between different types of discounts in the application.

protocol Discount {
    func apply(amount: Double) -> Double
}

class SeasonalDiscount: Discount {
    func apply(amount: Double) -> Double {
        return amount * 0.1
    }
}

class LoyaltyDiscount: Discount {
    func apply(amount: Double) -> Double {
        return amount * 0.15
    }
}

class DiscountCalculatorOCP {
    private var discounts: [Discount]

    init(discounts: [Discount]) {
        self.discounts = discounts
    }

    func calculateTotalDiscount(amount: Double) -> Double {
        var totalDiscount = 0.0
        for discount in discounts {
            totalDiscount += discount.apply(amount: amount)
        }
        return totalDiscount
    }
}

// usage
let seasonalDiscount = SeasonalDiscount()
let loyaltyDiscount = LoyaltyDiscount()
let discountCalculatorOCP = DiscountCalculatorOCP(discounts: [seasonalDiscount, loyaltyDiscount])
discountCalculatorOCP.calculateTotalDiscount(amount: 100)

Benefits of Adhering to OCP:

Improved Maintainability:
- Adding New Discount types doesn't require modifying exising code.
Enhanced Flexibility:
- Easily extendable with new discount class.
Greater Reusability:
- Discount logic is reusable across different parts of the application.

Drawbacks:

More Classes:
- Can lead to many small classes.
Complex Dependency Management:
- More dependencies to manage.
Design and Refactoring Overhead:
- Requires more effort to design and refactor.

Mitigating Drawbacks:

Balanced Approach:
- Apply OCP judiciously, balancing simplicity and extensibility.
Effective Documentation:
- Clear documentation helps navigate the codebase and understand class responsibilities.
Use Patterns and Frameworks:
- Design patterns (like Strategy) and dependency management tools can help.
Team Alignment:
- Ensure the team has a shared understanding of OCP and consistent practices.
Performance Profiling:
- Profile and optimize performance to manage any overhead introduced by adhering to OCP.

Conclusion:
By understanding and applying the Open/Closed Principle thoughtfully, you can create more maintainable, understandable, and flexible software.

Single Responsibility Principle
Liskov Substitution Principle
Check My GitHub Swift Playground Repo.

SOLID Design Principles

vinaykumar0339 — Sat, 29 Jun 2024 12:17:03 +0000

What is Desing Principles

Design principles are fundamental guidelines that software developers and engineers follow to create robust, maintainable, and scalable software systems.
These principles provide a foundation for making decisions throughout the software development lifecycle, ensuring that the code is of high quality and easy to understand, extend, and maintain

Acronym of SOLID

DEV Community: vinaykumar0339

JexLang: Write Once, Validate Everywhere — A Platform-Agnostic Expression Language

🎯 The Problem We All Face

😫 The Real Pain Points

1. Code Duplication Nightmare

2. Subtle Platform Differences

3. Hardcoded Logic = Deployment Pain

4. Testing Overhead

💡 What If There Was a Better Way?

🚀 Introducing JexLang

Why JavaScript-Like Syntax?

🛠️ How JexLang Works

1. Lexer (Tokenizer)

2. Parser

3. Interpreter

📖 Real-World Use Cases

1. Dynamic Form Validations

2. Business Rule Engines

3. Conditional UI Rendering

4. Workflow Automation

5. Feature Flags with Complex Logic

⚡ Quick Examples

Basic Expressions

Working with Context

Built-in Functions

Ternary Expressions

🔧 Getting Started

JavaScript/TypeScript

Java

🆚 How JexLang Compares

🗺️ Roadmap

🙏 Call to Action

📚 Resources

🎬 Final Thoughts

DataStructures In Computer Science - Introduction

What are Data Structures

Different Types of Data Structures

self vs Self in Swift Programming

self

Self

Example

Benefits of Self over exact Class Person as return type

Drawbacks of updateAgeWithExactClassType

Advantages of updateAgeWithSelfKeyword

Use of Self with protocols

Benefits

self

Self

Conclusion

PO vs P vs V in LLDB of Xcode

What is LLDB?

How to Interact with LLDB?

Let's take a look at below code Snippet.

What is po?

What is p?

What is v?

Differences

po (print object):

p (print):

v (dynamic resolution):

Conclusion:

Introduction to GCD (Grand Central Dispatch)

Apple Dispatch Framework

What is GCD?

How Work is submitted to DispatchQueue.

Serially or Concurrently vs Synchronously or Asynchronously

Will see now how to dispatch a block of work into Queue using DispatchQueue.main

Dispatch an work using Asynchronous.

Explanation for the above code

Benifits of using GCD Over Plain Threads Api

Abstraction of Complexity:

Efficient Resource Management:

Quality of Service (QoS) Support: (Will talk about this in depth in upcoming posts)

Conclusion

Achieving multi-threading by creating threads manually in Swift

What is Threading?

Why Use Threading?

Thread API in Swift

Pros of using Manual Threads

Crons of using Manual Threads

Benefits of `Self` over exact Class `Person` as return type

Drawbacks of `updateAgeWithExactClassType`

Advantages of `updateAgeWithSelfKeyword`

Use of `Self` with protocols